<html>
  <head>
    <meta content="text/html; charset=windows-1252"
      http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    <div class="moz-cite-prefix">On 07/15/2015 06:38 PM, melanie witt
      wrote:<br>
    </div>
    <blockquote
      cite="mid:AD1C7859-2F99-4A31-91E7-28B3DCC9404F@gmail.com"
      type="cite">
      <pre wrap="">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.</pre>
    </blockquote>
    <br>
    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.<br>
    <br>
    <br>
    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.<br>
    <br>
    But, you should not be able to do anything inside of child with a
    token scoped to parent.<br>
    <br>
    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?<br>
    <br>
    <br>
    <blockquote
      cite="mid:AD1C7859-2F99-4A31-91E7-28B3DCC9404F@gmail.com"
      type="cite">
      <pre wrap="">

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] <a class="moz-txt-link-freetext" href="https://review.openstack.org/#/q/status:open+project:openstack/nova+branch:master+topic:bp/nested-quota-driver-api,n,z">https://review.openstack.org/#/q/status:open+project:openstack/nova+branch:master+topic:bp/nested-quota-driver-api,n,z</a>
[2] <a class="moz-txt-link-freetext" href="https://review.openstack.org/#/c/103617/">https://review.openstack.org/#/c/103617/</a>
[3] <a class="moz-txt-link-freetext" href="https://review.openstack.org/182140/">https://review.openstack.org/182140/</a>
[4] <a class="moz-txt-link-freetext" href="http://logs.openstack.org/40/182140/12/check/check-tempest-dsvm-full/8e51c94/logs/testr_results.html.gz">http://logs.openstack.org/40/182140/12/check/check-tempest-dsvm-full/8e51c94/logs/testr_results.html.gz</a>

</pre>
      <br>
      <fieldset class="mimeAttachmentHeader"></fieldset>
      <br>
      <pre wrap="">__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: <a class="moz-txt-link-abbreviated" href="mailto:OpenStack-dev-request@lists.openstack.org?subject:unsubscribe">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a>
<a class="moz-txt-link-freetext" href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a>
</pre>
    </blockquote>
    <br>
  </body>
</html>