Open Stack

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?


>
> 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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150722/71750448/attachment.html>