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

[Akihiro Motoki]

To load heat service list, a project should be 'admin'. If a project other than 'admin' is used, even when a user has 'admin' role, heat service list cannot be retrieved.

'info' panel in horizon Admin dashboard tries to load the orchestration service list when a user has 'admin' role. As a result, a user will get 'Unable to get Orchestration service list.'.

In DevStack environment, to reproduce this issue,
login as 'admin' user, select 'demo' project or 'alt_demo' project, and visit 'System Information' of 'Admin' dashboard.
(If 'admin' project is selected, the error message is not shown.)

[Akihiro Motoki (amotoki)]

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.

[Andy Hsiang (yh418t)]

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.

[Akihiro Motoki (amotoki)]

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).

[Andy Hsiang (yh418t)]

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.

[Rabi Mishra (rabi)]

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.

[Rob Cresswell (robcresswell-deactivatedaccount)]

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.

[Akihiro Motoki (amotoki)]

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

[Akihiro Motoki (amotoki)]

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

[Akihiro Motoki (amotoki)]

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

[Akihiro Motoki (amotoki)]

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