Open Stack

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.

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

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