On Tue, Jun 28, 2016 at 3:38 AM, Henry Nash <henryna...@mac.com> wrote:
> Hi Matt, > > So the keystone changes were intentional. From Mitaka onwards, a domain is > represented as a project which is “acting as a domain” (it has an attribute > “is_domain” set to true). The situation you describe, where what were top > level projects now have the project acting as the default domain as their > parent, is what I would expect to happen after the update. > > During Mitaka development, we worked with the cinder folks - who were to > re-designing their quota code anyway - and this was modified to take > account of the project structure. I’m not sure if the quota semantics you > see are what was intended (I’ll let the cinder team comment). Code can, if > desired, distinguish the case of top projects that are at the top level, vs > projects somewhere way down the hierarchy, by looking at the parent and > seeing if it is a project acting as a domain. > Just to add to Henry's answer, checking if the parent is a project acting as a domain is just matter of comparing the parent_id with the domain_id, if they are equal, it means the parent is a project acting as a domain. > > Henry > keystone core > > On 27 Jun 2016, at 17:13, Matt Fischer <m...@mattfischer.com> wrote: > > We upgraded our dev environment last week to Keystone stable/mitaka. Since > then we're unable to show or set quotas on projects of which the admin is > not a member. Looking at the cinder code, it seems that cinder is pulling a > project list and attempting to determine a hierarchy. On Liberty Keystone, > projects seem to lack parents: > > <Project description=Admin Tenant, domain_id=default, enabled=True, > id=9e839870dd0d4a2f96f9d71b7e7c5a4e, is_domain=False, links={u'self': u' > https://liberty-endpoint:5000/v3/projects/9e839870dd0d4a2f96f9d71b7e7c5a4e'}, > name=admin, parent_id=None, subtree=None> > > In Mitaka, it seems that projects are children of the default domain: > > <Project description=Admin Tenant, domain_id=default, enabled=True, > id=4764ba822ecb43e582794b875751924c, is_domain=False, links={u'self': u' > http://mitaka-endpoint:5000/v3/projects/4764ba822ecb43e582794b875751924c'}, > name=admin, parent_id=default, subtree=None> > > In Liberty since all projects were parentless, the authorize_* code blocks > were skipped since both conditionals were false: > > > https://github.com/openstack/cinder/blob/stable/liberty/cinder/api/contrib/quotas.py#L174-L191 > > But now in Mitaka, the code is run, and it fails out since the projects > are "brothers", both with the parent of the default domain, but not > hierarchically related. > > Previously it was a useful ability for us to be able to (as admins) set > and view quotas for cinder projects. Now we need to scope into the user's > project to even be able to view their quotas, much less change them. This > seems broken, but I'm not sure where the issue is or why the keystone > behavior changed. Is this the expected behavior? > > __________________________________________________________________________ > 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 > > -- Rodrigo Duarte Sousa Senior Quality Engineer @ Red Hat MSc in Computer Science http://rodrigods.com
__________________________________________________________________________ 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