Open Stack

Michal & Raildo,

So the keystone patch (https://review.openstack.org/#/c/270057/ <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 <raildom at gmail.com> wrote:
> 
> See responses inline.
> 
> On Mon, Feb 1, 2016 at 6:25 PM Michał Dulko <michal.dulko at intel.com <mailto: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/ <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://OpenStack-dev-request@lists.openstack.org/?subject:unsubscribe>
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev <http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org <mailto:OpenStack-dev-request at lists.openstack.org>?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev <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/20160217/5497ef26/attachment-0001.html>