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

[Matt Fischer]

On Tue, Jun 28, 2016 at 12:32 PM, Potter, Nathaniel <
nathaniel.pot...@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.
__
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

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

[Potter, Nathaniel]

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 ☺. 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



From: Matt Fischer [mailto:m...@mattfischer.com]
Sent: Tuesday, June 28, 2016 7:36 AM
To: OpenStack Development Mailing List (not for usage questions) 
<openstack-dev@lists.openstack.org>
Subject: Re: [openstack-dev] [cinder] [keystone] cinder quota behavior 
differences after Keystone mitaka upgrade

Thanks Henry,

From a Keystone POV I think it makes sense, but it's causing some operational 
headaches, so I'm curious what the cinder team thinks about this. Not being 
able to see or set someone's quota as an admin is frustrating for dealing with 
support requests.


On Tue, Jun 28, 2016 at 12:38 AM, Henry Nash 
<henryna...@mac.com<mailto: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.

Henry
keystone core
On 27 Jun 2016, at 17:13, Matt Fischer 
<m...@mattfischer.com<mailto: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:

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:

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 d

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

[Matt Fischer]

Thanks Henry,

>From a Keystone POV I think it makes sense, but it's causing some
operational headaches, so I'm curious what the cinder team thinks about
this. Not being able to see or set someone's quota as an admin is
frustrating for dealing with support requests.


On Tue, Jun 28, 2016 at 12:38 AM, Henry Nash  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.
>
> Henry
> keystone core
>
> On 27 Jun 2016, at 17:13, Matt Fischer  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:
>
>  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:
>
>  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
>
>
__
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

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

[Rodrigo Duarte]

On Tue, Jun 28, 2016 at 3:38 AM, Henry Nash  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  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:
>
>  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:
>
>  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

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

[Henry Nash]

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.

Henry
keystone core
> On 27 Jun 2016, at 17:13, Matt Fischer  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:
> 
>  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:
> 
>  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

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

[Matt Fischer]

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:

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:

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