Bug 890510 - Horizon not usable using the keystone roles from the guide
Horizon not usable using the keystone roles from the guide
Status: CLOSED CURRENTRELEASE
Product: Red Hat OpenStack
Classification: Red Hat
Component: doc-Getting_Started_Guide (Show other bugs)
2.1
Unspecified Unspecified
unspecified Severity high
: ---
: ---
Assigned To: Stephen Gordon
ecs-bugs
: Documentation
Depends On:
Blocks: 888516
  Show dependency treegraph
 
Reported: 2012-12-27 06:59 EST by Julie Pichon
Modified: 2015-02-15 17:02 EST (History)
5 users (show)

See Also:
Fixed In Version: Red_Hat_OpenStack_Preview-Getting_Started_Guide-2-web-en-US-1.0-11.el6eng
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2013-02-21 15:30:20 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description Julie Pichon 2012-12-27 06:59:33 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.


Additional info:

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.
Comment 2 Stephen Gordon 2013-01-25 10:54:16 EST
commit d43766fbbf79d60ba1a360fc4d60a7f149652932

- 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.
Comment 3 Julie Pichon 2013-01-25 11:13:55 EST
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.
Comment 4 Stephen Gordon 2013-01-25 11:34:06 EST
(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.
Comment 5 Stephen Gordon 2013-01-25 11:37:21 EST
commit 122db996267b653e28585d8fa971d919e09f5459

Revert "BZ#890510 - Horizon requires "Member" role for some functionality."
    
This reverts commit d43766fbbf79d60ba1a360fc4d60a7f149652932 as a result of feedback in:
    
    https://bugzilla.redhat.com/show_bug.cgi?id=890510#c3
Comment 6 Stephen Gordon 2013-01-25 13:26:11 EST
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.
Comment 7 Stephen Gordon 2013-01-25 14:10:33 EST
commit f0421292fbd423ed6a70354d1dbfdcd1d2f286b9

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
to:
    
- Add the creation of the 'Member' role as an additional step.
- Explain where Horizon can be configured to use a different role.
Comment 8 Stephen Gordon 2013-01-25 16:47:07 EST
Fixed in Red_Hat_OpenStack_Preview-Getting_Started_Guide-2-web-en-US-1.0-11.el6eng

Note You need to log in before you can comment on or make changes to this bug.