Open Stack

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 <raildom at gmail.com> 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 <henrynash9 at mac.com> 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 <raildom at gmail.com> wrote:
>>
>> See responses inline.
>>
>> On Mon, Feb 1, 2016 at 6:25 PM Michał Dulko <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/  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
>>>
>> __________________________________________________________________________
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: OpenStack-dev-request at lists.openstack.org
>> ?subject:unsubscribe
>> 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?subject:unsubscribe
>> 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?subject:unsubscribe
> 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/a9ae15ac/attachment.html>