Red Hat Bugzilla – Bug 890510
Horizon not usable using the keystone roles from the guide
Last modified: 2015-02-15 17:02:01 EST
Description of problem:
Following the Getting started guide, notably the role creation in keystone, much of the functionality in Horizon is not usable. See bug 889589, bug 888516, bug 889765 for examples and steps to reproduce the problem.
This is happening because Horizon expects the default Keystone role to be "Member" (see OPENSTACK_KEYSTONE_DEFAULT_ROLE in openstack_dashboard/local/local_settings.py), but following the guide we create a default role of "user".
For now, it's probably safer/easier to change the documentation to create a "Member" role instead of a "user" role.
The current workaround is to update the /usr/share/openstack-dashboard/openstack_dashboard/local/local_settings.py file, change OPENSTACK_KEYSTONE_DEFAULT_ROLE to "user" and restart httpd. But such a change would probably be overwritten when upgrading the package later on.
- Modified the Keystone chapter to create a Member role.
- Added this statement to the Horizon chapter:
"Fully functional access to the Horizon dashboard requires a user account that has been granted the <literal>Member</literal> role. Accessing the Horizon dashboard with user accounts that do not have the <literal>Member</literal> role is not recommended."
Obviously this statement is a bit problematic, but it results from the fact that saying that users without a Member role can't access the dashboard at all is inaccurate. It appears they can access it but some functionality will fail to work.
Ideally if we don't intend for that functionality to work without the Member role then we shouldn't allow users without it to log in at all (or at least make the failures more graceful) but that is just my 2c. I see Bug # 888516 remains open so hopefully this situation is improved there.
If I may nitpick, this isn't wholly accurate: the user doesn't need to be *assigned* that role -- the role simply needs to exist in Keystone, in general. That is, if we left the documentation as is, and simply added the requirement to run "keystone role-create --name Member" this would also be enough for Horizon to function normally.
There isn't much that can be done as part of bug #888516, since this is controlled by a user setting (see my comment in bug #904154 btw, I believe I made a mistake when mentioning the /usr/share/ file and it should already be possible to specify user-defined settings elsewhere). Bug #888516 will be closed when the documentation is fixed and it becomes possible to get a working Horizon following the guide.
(In reply to comment #3)
> If I may nitpick, this isn't wholly accurate: the user doesn't need to be
> *assigned* that role -- the role simply needs to exist in Keystone, in
> general. That is, if we left the documentation as is, and simply added the
> requirement to run "keystone role-create --name Member" this would also be
> enough for Horizon to function normally.
Ok, I will revert my change and try again. My interpretation was based on the fact that the only reason we create the user role in the guide currently is to then immediately assign it to the reader's first "non-admin" user.
> There isn't much that can be done as part of bug #888516, since this is
> controlled by a user setting (see my comment in bug #904154 btw, I believe I
> made a mistake when mentioning the /usr/share/ file and it should already be
> possible to specify user-defined settings elsewhere). Bug #888516 will be
> closed when the documentation is fixed and it becomes possible to get a
> working Horizon following the guide.
Why can't the logging for this issue be improved to say what is actually wrong? Why do we allow logins when a role (apparently) crucial to the service's operation is not present?
Both of these are questions I would expect to be resolved under Bug # 888516 and I would expect failure to resolve them to generate support cases.
Revert "BZ#890510 - Horizon requires "Member" role for some functionality."
This reverts commit d43766fbbf79d60ba1a360fc4d60a7f149652932 as a result of feedback in:
Thinking further on the documentation I think the correct change is to add creation of a Member role to steps in the Horizon chapter, rather than to the Keystone chapter itself.
My reasoning is:
- This is in line with the way we handle service specific Keystone configurations for the other components.
- It's much less likely to be missed by a user setting up Horizon.
BZ#890510 - Added Member role creation step to Horizon procedure.
The procedure for setting up Horizon didn't mention that by default it
relies on the presence of a 'Member' role. I have updated the procedure
- Add the creation of the 'Member' role as an additional step.
- Explain where Horizon can be configured to use a different role.
Fixed in Red_Hat_OpenStack_Preview-Getting_Started_Guide-2-web-en-US-1.0-11.el6eng