heat service list cannot be loaded if a project is not 'admin'

The last policy.json in the heat repository is defined as follows:

  "context_is_admin": "role:admin and is_admin_project:True",
  "service:index": "rule:context_is_admin",

This problem cannot be solved simply by copying policy.json from heat project.

is_admin_project attribute is defined by oslo_context in most project.
(commit d3af1d06b4046c25c199bf1c389a9e440a634bc6 in oslo_context repo).
However, horizon (openstack_auth) has a different implementation.
"is_admin_project" support needs to be added.

Hi, Is this not what's expected? should each user with admin role be able to view the heat engine service? this is the same behavior i observed when listing heat service via cli.

I am not a heat guy and do not know the background on why service-list is limited to 'admin' project by default.
As you see, in heat policy.json, 'admin' project and 'admin' role are distinguished.

I see two points.
- The one is horizon policy engine is not compatible with other projects based on oslo_context.
- The other is why heat policy.json limits service-list to 'admin' project (is_admin_project).

Hi, I'm relatively new to openstack, someone else might want to comment on this. I just want to share what i found by going through the steps. My guess is that project admins (or user with admin role outside of admin project) probably do not need to know the heat service engine details.

So this is expected behaviour from heat. For heat, 'admin' is one with 'admin' role in 'admin' project. We use 'is_admin_project' from the context in heat policy.json, which is set based on the admin_project in keystone.conf and it's backward compatible(is_admin_project falls back to True with oslo.context when there is no admin project defined). Therefore, 'service list' is available only to the 'admin' and not a user with admin role in any project.

We do use a 'project_admin' for certain stuff in our policy.json to make it compatible with other project policies. So if it's an issue for horizon then we can probably change it.

This may indicate a problem or gap in Horizons policy handling, but it seems that the policy is functioning as expected on the heat side. I've bumped it from RC2 anyway, as it is not a High priority bug.

Thanks Rabi for clarifying the situation.

I agree that it is a gap in horizon policy handling. I think it is a high priority topic in the next cycle to sync horizon policy handling with other projects in the standard way. We may need to use oslo.context as well.
It is a key topic for keystone v3 world.

Here is a link to the discussion on horizon channel for additional information.
http://eavesdrop.openstack.org/irclogs/%23openstack-horizon/%23openstack-horizon.2016-09-21.log.html#t2016-09-21T09:08:29

Related bug: https://bugs.launchpad.net/horizon/+bug/1624834

Woops... the related bug is https://bugs.launchpad.net/keystone/+bug/968696

heat panel is split out to heat-dashboard. Retargeting to heat-dashboard.