[openstack-dev] [nova] Replacing user based policies in Nova

Tim Bell Tim.Bell at cern.ch
Fri Jun 3 18:06:18 UTC 2016


With https://review.openstack.org/324068 (thanks ☺), the key parts of user based policies as currently deployed would be covered in the short term. However, my understanding is that this functionality needs to be replaced with something sustainable in the long term and consistent with the approach that permissions should be on a per-project basis rather than a per-instance/object.

Looking at the use cases:


-          Shared pools of quota between smaller teams

-          Protection from a VM created by one team being shutdown/deleted/etc by another

I think much of this could be handled using nested projects in the future.

Specifically,


-          Given a project ‘long tail’, smaller projects could be created under that which would share the total ‘long tail’ quota with other siblings

-          Project ‘higgs’ could be a sub-project of ‘long tail’ and have its own role assignments so that the members of the team of sub-project ‘diphoton’ could not affect the ‘higgs’ VMs

-          The administrator of the project ‘long tail’ would be responsible for setting up the appropriate user<->role mappings for the sub projects and not require tickets to central support teams

-          This could potentially be taken to the ‘personal project’ use case following the implementation of https://review.openstack.org/#/c/324055 in Keystone and implementation in other projects

Does this sound doable ?

The major missing piece that I would see for the implementation would the nested quotas in Nova/Cinder. The current structure seems to be try to build a solution on top of the delimiter library but this is early days.

I’d be happy for feedback on the technical viability of this proposal and then I can review with those who have raised the need to see if it would work for them.

Tim


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160603/3bdd329a/attachment-0001.html>


More information about the OpenStack-dev mailing list