[openstack-dev] [keystone][cinder] Projects acting as a domain at the top of the project hierarchy

Raildo Mascena raildom at gmail.com
Wed Feb 17 14:06:18 UTC 2016


Henry,

I know about two patches related:
Fixes cinder quota mgmt for keystone v3 -
https://review.openstack.org/#/c/253759
Split out NestedQuotas into a separate driver -
https://review.openstack.org/#/c/274825

The first one was abandoned, so I think the second patch is enough to fix
this issue.

Cheers,

Raildo

On Wed, Feb 17, 2016 at 8:07 AM Henry Nash <henrynash9 at mac.com> wrote:

> Michal & Raildo,
>
> So the keystone patch (https://review.openstack.org/#/c/270057/) is now
> merged.  Do you perhaps have a cinder patch that I could review so we can
> make sure that this is likely to work with the new projects acting as
> domains? Currently it is the cinder tempest tests that are failing.
>
> Thanks
>
> Henry
>
>
> On 2 Feb 2016, at 13:30, Raildo Mascena <raildom at gmail.com> wrote:
>
> See responses inline.
>
> On Mon, Feb 1, 2016 at 6:25 PM Michał Dulko <michal.dulko at intel.com>
> wrote:
>
>> On 01/30/2016 07:02 PM, Henry Nash wrote:
>> > Hi
>> >
>> > One of the things the keystone team was planning to merge ahead of
>> milestone-3 of Mitaka, was “projects acting as a domain”. Up until now,
>> domains in keystone have been stored totally separately from projects, even
>> though all projects must be owned by a domain (even tenants created via the
>> keystone v2 APIs will be owned by a domain, in this case the ‘default’
>> domain). All projects in a project hierarchy are always owned by the same
>> domain. Keystone supports a number of duplicate concepts (e.g. domain
>> assignments, domain tokens) similar to their project equivalents.
>> >
>> > <snip>
>> >
>> > I’ve got a couple of questions about the impact of the above:
>> >
>> > 1) I already know that if we do exactly as described above, the cinder
>> gets confused with how it does quotas today - since suddenly there is a new
>> parent to what it thought was a top level project (and the permission rules
>> it encodes requires the caller to be cloud admin, or admin of the root
>> project of a hierarchy).
>>
>> These problems are there because our nested quotas code is really buggy
>> right now. Once Keystone merges a fix allowing non-admin users to fetch
>> his own project hierarchy - we should be able to fix it.
>>
>
> ++ The patch to fix this problem are closer to be merged, there is just
> minor comments to fix: https://review.openstack.org/#/c/270057/  So I
> believe that we can fix this bug on cinder in in next days.
>
>>
>> > 2) I’m not sure of the state of nova quotas - and whether it would
>> suffer a similar problem?
>>
>> As far as I know Nova haven't had merged nested quotas code and will not
>> do that in Mitaka due to feature freeze.
>
> Nested quotas code on Nova is very similar with the Cinder code and we are
> already fixing the bugs that we found on Cinder. Agreed that It will not be
> merged in Mitaka due to feature freeze.
>
>>
>> > 3) Will Horizon get confused by this at all?
>> >
>> > Depending on the answers to the above, we can go in a couple of
>> directions. The cinder issues looks easy to fix (having had a quick look at
>> the code) - and if that was the only issue, then that may be fine. If we
>> think there may be problems in multiple services, we could, for Mitaka,
>> still create the projects acting as domains, but not set the parent_id of
>> the current top level projects to point at the new project acting as a
>> domain - that way those projects acting as domains remain isolated from the
>> hierarchy for now (and essentially invisible to any calling service). Then
>> as part of Newton we can provide patches to those services that need
>> changing, and then wire up the projects acting as a domain to their
>> children.
>> >
>> > Interested in feedback to the questions above.
>>
>> __________________________________________________________________________
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>> <http://OpenStack-dev-request@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-request at 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-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160217/07a14e1a/attachment.html>


More information about the OpenStack-dev mailing list