Open Stack

On 7/22/2015 10:18 PM, Adam Young wrote:
> On 07/15/2015 06:38 PM, melanie witt wrote:
>> Hi Everyone,
>>
>> Recently I have started reviewing the patch series about nested quotas in nova [1] and I'm having trouble understanding where we currently are with identity v3 support in nova. From what I read in a semi recent proposal [2] I think things mostly "just work" if you configure to run with v3, but there are some gaps.
>>
>> Nested quotas use the concept of parent/child projects in keystone v3 to allow parent projects to delegate quota management to subprojects. This means we'd start getting requests with a token scoped to the parent project to modify quota of a child project.
>
> Don't think of it as a nested project, in this case...The project that
> is having its quota set is a resource inside the project that the user
> authenticated in as.
>
>
> If Parent -> child...you should not be able to scope to anything but the
> parent project in order to be able to set the quota for child.
>
> But, you should not be able to do anything inside of child with a token
> scoped to parent.
>
> The one place this gets tricky is that every project should be able to
> query its own quota.  But that is true now, is it not?

You can, the default policy for show is admin_or_owner:

http://git.openstack.org/cgit/openstack/nova/tree/etc/nova/policy.json?id=12.0.0.0b1#n333

>
>
>>
>> With keystone v3 we could get requests with tokens scoped to parent projects that act upon child project resources for all APIs in general.
>>
>> The first patch in the series [3] removes the top-level validation check for context.project_id != project_id in URL, since with v3 it's a supported thing for a parent project to act on child project resources. (I don't think it's completely correct in that I think it would allow unrelated projects to act on one another)
>>
>> Doing this fails the keypairs and security groups tempest tests [4] that verify that one project cannot create keypairs or security group rules in a different project.
>>
>> Question: How can we handle project_id mismatch in a way that supports both keystone v2 and v3? Do we augment the check to fall back on checking if "is parent of" using keystone API if there's a project_id mismatch?
>>
>> Question: Do we intend to, for example, allow creation of keypairs by a parent on behalf of child being that the private key is returned to the caller?
>>
>> Basically, I feel stuck on these reviews because it appears to me that nova doesn't fully support identity v3 yet. From what I checked, there aren't yet Tempest jobs running against identity v3 either.
>>
>> Can anyone shed some light on this as I'm trying to see a way forward with the nested quotas reviews?
>>
>> Thanks,
>> -melanie (irc: melwitt)
>>
>>
>> [1]https://review.openstack.org/#/q/status:open+project:openstack/nova+branch:master+topic:bp/nested-quota-driver-api,n,z
>> [2]https://review.openstack.org/#/c/103617/
>> [3]https://review.openstack.org/182140/
>> [4]http://logs.openstack.org/40/182140/12/check/check-tempest-dsvm-full/8e51c94/logs/testr_results.html.gz
>>
>>
>>
>> __________________________________________________________________________
>> 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
>

-- 

Thanks,

Matt Riedemann