Open Stack

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://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/20160202/8d8678ce/attachment.html>