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

Reply via email to