Re: [openstack-dev] [nova] Status of identity v3 support
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
Re: [openstack-dev] [nova] Status of identity v3 support
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
Re: [openstack-dev] [nova] Status of identity v3 support
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-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
Re: [openstack-dev] [nova] Status of identity v3 support
On 7/15/2015 5: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. 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 I've added this to the meetup etherpad for next week: https://etherpad.openstack.org/p/liberty-nova-midcycle Since bknudson worked on the keystone v3 spec for nova and will be sitting in during the meetup next week at some point (since he's local). -- 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
[openstack-dev] [nova] Status of identity v3 support
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. 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 signature.asc Description: Message signed with OpenPGP using GPGMail __ 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
