Open Stack

----- Original Message -----
> From: "Pasquale Porreca" <pasquale.porreca at dektech.com.au>
> To: "OpenStack Development Mailing List (not for usage questions)" <openstack-dev at lists.openstack.org>
> Sent: Thursday, February 19, 2015 3:24:03 AM
> Subject: Re: [openstack-dev] [Keystone] [devstack] About _member_ role
> 
> Analyzing Horizon code I can confirm that the existence of _member_ role
> is required, so the commit https://review.openstack.org/#/c/150667/
> introduced the bug in devstack. More details and a fix proposal in my
> change submission: https://review.openstack.org/#/c/156527/
> 
> On 02/18/15 10:04, Pasquale Porreca wrote:
> > I saw 2 different bug report that Devstack dashboard gives an error when
> > trying to manage projects
> > https://bugs.launchpad.net/devstack/+bug/1421616 and
> > https://bugs.launchpad.net/horizon/+bug/1421999
> > In my devstack environment projects were working just fine, so I tried a
> > fresh installation to see if I could reproduce the bug and I could
> > confirm that actually the bug is present in current devstack deployment.
> > Both reports point to the lack of _member_ role this error, so I just
> > tried to manually (i.e. via CLI) add a _member_ role and I verified that
> > just having it - even if not assigned to any user - fix the project
> > management in Horizon.
> >
> > I didn't deeply analyze yet the root cause of this, but this behaviour
> > seemed quite weird, this is the reason I sent this mail to dev list.
> > Your explanation somewhat confirmed my doubts: I presume that adding a
> > _member_ role is merely a workaround and the real bug is somewhere else
> > - in Horizon code with highest chance.

Ok, so I dug into this today. The problem is that the 'member_role_name' that is set in keystone CONF is only being read that first time when it creates the default member role if not already present. At all other times keystone works with the role id set by 'member_role_id' which has a default value. So even though horizon is looking and finding a member_role_name it doesn't match up with what keystone is doing when it uses member_role_id. 

IMO this is wrong and i filed a bug against keystone: https://bugs.launchpad.net/keystone/+bug/1426184

In the mean time it works if you add both the member_role_name and member_role_id to the config file. Unfortunately adding an ID means you need to get the value from keystone and then set it into keystone's own config file, so restarting keystone. This is similar to a review I had for policy so I modified that and put up my own review https://review.openstack.org/#/c/159690

Given the keystone restart I don't know if it's cleaner, however that's the way i know to solve this 'properly'. 


Jamie

> > On 02/17/15 21:01, Jamie Lennox wrote:
> >> ----- Original Message -----
> >>> From: "Pasquale Porreca" <pasquale.porreca at dektech.com.au>
> >>> To: "OpenStack Development Mailing List (not for usage questions)"
> >>> <openstack-dev at lists.openstack.org>
> >>> Sent: Tuesday, 17 February, 2015 9:07:14 PM
> >>> Subject: [openstack-dev]  [Keystone] [devstack] About _member_ role
> >>>
> >>> I proposed a fix for a bug in devstack
> >>> https://review.openstack.org/#/c/156527/ caused by the fact the role
> >>> _member_ was not anymore created due to a recent change.
> >>>
> >>> But why is the existence of _member_ role necessary, even if it is not
> >>> necessary to be used? Is this a know/wanted feature or a bug by itself?
> >> So the way to be a 'member' of a project so that you can get a token
> >> scoped to that project is to have a role defined on that project.
> >> The way we would handle that from keystone for default_projects is to
> >> create a default role _member_ which had no permissions attached to it,
> >> but by assigning it to the user on the project we granted membership of
> >> that project.
> >> If the user has any other roles on the project then the _member_ role is
> >> essentially ignored.
> >>
> >> In that devstack patch I removed the default project because we want our
> >> users to explicitly ask for the project they want to be scoped to.
> >> This patch shouldn't have caused any issues though because in each of
> >> those cases the user is immediately granted a different role on the
> >> project - therefore having 'membership'.
> >>
> >> Creating the _member_ role manually won't cause any problems, but what
> >> issue are you seeing where you need it?
> >>
> >>
> >> Jamie
> >>
> >>
> >>> --
> >>> Pasquale Porreca
> >>>
> >>> DEK Technologies
> >>> Via dei Castelli Romani, 22
> >>> 00040 Pomezia (Roma)
> >>>
> >>> Mobile +39 3394823805
> >>> Skype paskporr
> >>>
> >>>
> >>> __________________________________________________________________________
> >>> OpenStack Development Mailing List (not for usage questions)
> >>> Unsubscribe:
> >>> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> >>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >>>
> >> __________________________________________________________________________
> >> OpenStack Development Mailing List (not for usage questions)
> >> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 
> --
> Pasquale Porreca
> 
> DEK Technologies
> Via dei Castelli Romani, 22
> 00040 Pomezia (Roma)
> 
> Mobile +39 3394823805
> Skype paskporr
> 
> 
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>