Hi all, I discussed the change with other cores in -keystone and, looking at the API change guidelines, it should be an allowed API change.
I had a doubt whether the rule "Changing or removing a property in a resource representation." could make it a forbidden API change or not. However, since it is not changing the returned attribute itself (type), but only the returned data in it, it should be okay. [1] http://specs.openstack.org/openstack/api-wg/guidelines/evaluating_api_changes.html Regards, Samuel On Wed, Feb 17, 2016 at 11:06 AM, Raildo Mascena <[email protected]> wrote: > 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 > >
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
