Bug 890510

Summary:	Horizon not usable using the keystone roles from the guide
Product:	Red Hat OpenStack	Reporter:	Julie Pichon <jpichon>
Component:	doc-Getting_Started_Guide	Assignee:	Stephen Gordon <sgordon>
Status:	CLOSED CURRENTRELEASE	QA Contact:	ecs-bugs
Severity:	high	Docs Contact:
Priority:	unspecified
Version:	2.1	CC:	athomas, breeler, jpichon, mrunge, sgordon
Target Milestone:	---	Keywords:	Documentation
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
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 20:30:20 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:
Bug Depends On:
Bug Blocks:	888516

Description Julie Pichon 2012-12-27 11:59:33 UTC

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 15:54:16 UTC

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 16:13:55 UTC

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 16:34:06 UTC

(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 16:37:21 UTC

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 18:26:11 UTC

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 19:10:33 UTC

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 21:47:07 UTC

Fixed in Red_Hat_OpenStack_Preview-Getting_Started_Guide-2-web-en-US-1.0-11.el6eng