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 <[email protected]> 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 <[email protected]> wrote: > > See responses inline. > > On Mon, Feb 1, 2016 at 6:25 PM Michał Dulko <[email protected]> > 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: >> [email protected]?subject:unsubscribe >> <http://[email protected]/?subject:unsubscribe> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: [email protected]?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: [email protected]?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
