[openstack-dev] [cinder] [keystone] cinder quota behavior differences after Keystone mitaka upgrade

Matt Fischer matt at mattfischer.com
Tue Jun 28 18:43:11 UTC 2016


On Tue, Jun 28, 2016 at 12:32 PM, Potter, Nathaniel <
nathaniel.potter at intel.com> wrote:

> Hi all,
>
>
>
> I did some digging into this on the cinder side, and it gets a little
> complicated. So, before the target and context are passed into the
> _authorize_show method, they’re retrieved through the get_project_hierarchy
> method in cinder.quota_utils [1]. In that method, they will only have their
> parent_id set if the parent_id isn’t the same as their domain_id [2] – if
> those two fields are equal the parent_id field for the returned
> generic_project object will be None. Based on what Henry said it seems like
> those two fields being the same implies that the project is at the top
> level because its parent is the domain itself (I’m guessing that should be
> true of the admin project?).
>
>
>
> So in your example you have the admin project whose domain_id is default
> and whose parent_id is also default, meaning that the parent_id passed into
> _authorize_show is going to be None. If the target project whose quota you
> want to show is a ‘brother’ project to it and has a parent of default in
> the default domain, it should also have no parent set. Do you happen to
> know which of the three exceptions in _authorize_show  you’re hitting?
>
>
>
> If the admin context project is the one you pasted, it definitely won’t
> have a set parent because its parent and domain are the same. That would
> rule out the exceptions on line 130 and 134 for your  issue because they
> both rely on the context project having a set parent_id [3]. That would
> just leave the case where the target project for the quota you want to be
> showing does have a non-domain parent and isn’t a part of the subtree for
> the admin context you’re making the call with.
>
>
>
> Sorry for a bit of a braindump here, I was just trying to look at all of
> the possibilities to see if any of them could be of help J. I think it
> would definitely be useful to know how exactly it’s failing out for you so
> we can make sure it works the way it should, because I believe the intent
> is definitely to have admins be able to view and set all user quotas.
>
>
>
> Thanks,
>
> Nate
>
>
>
> [1]
> https://github.com/openstack/cinder/blob/master/cinder/api/contrib/quotas.py#L170-L175
>
> [2]
> https://github.com/openstack/cinder/blob/master/cinder/quota_utils.py#L110-L112
>
> [3]
> https://github.com/openstack/cinder/blob/master/cinder/api/contrib/quotas.py#L125-L134
>

We're hitting the first exception:

https://github.com/openstack/cinder/blob/stable/liberty/cinder/api/contrib/quotas.py#L178-L180

In our environment currently everything should have the default domain as
the parent except for some heat stuff.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160628/883c4c9c/attachment.html>


More information about the OpenStack-dev mailing list