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-requ...@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-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
--
Thanks,
Matt Riedemann
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
