On 07/23/2015 10:08 AM, Matt Riedemann wrote:
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
So, this is a manifaestation of "Admin" ness not properly scoped
https://bugs.launchpad.net/keystone/+bug/968696
Note that it does not say "admin on the project" but rather "admin
anywhere" which is endmic throughout opentstack, and something we are
working to fix.
Policy rules that do not explicitly match scope for every token need to
be rewritten to scope them properly.
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
__________________________________________________________________________
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
