As I said in your code review I don't really like an approach that require saving a random generate id in the config file and a keystone restart. I would like you to review my proposal if you don't mind https://review.openstack.org/156527
I think this is a quite important bug in devstack since it prevents users to create or manage projects, so I would ask anyone interested - especially devstack core reviewers - to give a look to the bug report https://bugs.launchpad.net/devstack/+bug/1421616 and the proposed fixes. On 02/27/15 06:38, Jamie Lennox wrote: > > ----- Original Message ----- >> From: "Pasquale Porreca" <pasquale.porr...@dektech.com.au> >> To: "OpenStack Development Mailing List (not for usage questions)" >> <openstack-dev@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.porr...@dektech.com.au> >>>>> To: "OpenStack Development Mailing List (not for usage questions)" >>>>> <openstack-dev@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-requ...@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-requ...@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-requ...@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-requ...@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-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
