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