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
Development Mailing List (not for usage questions)
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 c
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
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
>
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 dom
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
