<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, Dec 25, 2013 at 11:00 PM, Ulrich Schwickerath <span dir="ltr"><<a href="mailto:ulrich.schwickerath@cern.ch" target="_blank">ulrich.schwickerath@cern.ch</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">Dear all,<br>
<br>
I'd like to trigger a new discussion about the future of quota management in OpenStack. Let me start with our main user story to clarify what we need.<br>
I'm working for CERN for the IT departement. We're providing computing resources to our customers, either through traditional batch farms or through an OpenStack IaaS<br>
infrastructure. Our main customers are the LHC experiments, which by themselves are fairly large dynamic organizations with complex internal structures, with specific requirements<br>
and many thousand users from many different countries and regions. Computing resources are centralized, and each customer organization gets it's share of the cake.<br>
<br>
Instead of trying to keep track of the internal structures of our customers and their changing needs, we need a way to allocate one piece of the big cake to each customer (and adjust it regularely), and give them the possibility to manage these resources themselves. What I have in mind here is the idea of a "Quota delegation":<br>
<br>
- The main resource manager determines the fractions of the resources for each customer<br>
- He allocates a quota to each customer by giving it to a "computing coordinater" which is nominated by the customer<br>
- the computing coordinater in turn takes his piece of the cake, chops it up and gives it to the coordinators of the different research groups in his experiment<br>
<br>
and so on.<br>
<br></blockquote><div><br></div><div>This sounds like what I would imagine should be a very common use case, so it would be really great if we can support this. And as always support means tested in gate.</div><div><br></div>
<div>To put this in other terms, it sounds like you want one role to set per project quota's, and another role to set user quotas for that specific project (<a href="https://blueprints.launchpad.net/nova/+spec/per-user-quotas">https://blueprints.launchpad.net/nova/+spec/per-user-quotas</a>).</div>
<div><br></div><div>Both of those quota mechanisms exist today, but the roles you desire do not exist by default. So I think all that is needed to support your use case is make sure nova works with your desired roles. That involves fixing any issues and writing a test we can gate on.</div>
<div><br></div><div>So I think the outcome of this work will consist of:</div><div><br></div><div>* Changing the default policy.json file we use</div><div>* An easy upgrade path</div><div>* Documentation explaining the new default roles</div>
<div>* Some small changes to nova to understand the new roles, along with unit tests.</div><div>* Tempest tests</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
I'd like to ask people for their opinion on how such a schema should be implemented. There are several aspects which need to be taken into account here:<br>
- There are people with different roles in this game:<br>
+- the main resource manager role is a super user role which can but does not have to be identical to the cloud manager.<br>
Persons with this role should be able to change all numbers down in the tree. In general, the cloud manager and the resource manager role are<br>
not identical in my opinion. Persons with this role should also be able to nominate other resource managers and give them a fraction of the resources<br>
+- a normal resource manager is a bit like the main resource manager, with the exception that he can only manage the fraction of the resources he was allocated by a person "above" him<br>
+- a normal user: persons with this role can only consume resources<br></blockquote><div><br></div><div>This can be supported via our policy logic (<a href="http://git.openstack.org/cgit/openstack/nova/tree/etc/nova/policy.json">http://git.openstack.org/cgit/openstack/nova/tree/etc/nova/policy.json</a>). By default we don't define that many roles by default.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<br>
- several people can have the same role. This is necessary to be able to cover eg. holiday season or sick leave periods where one manager is not available. Maybe introducing a group concept here would be appropriate, in a way that roles are assigned to groups and people are assigned to the groups instead of assigning roles directly to individuals.<br>
</blockquote><div><br></div><div>I think keystone supports this today.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<br>
- When I say "Quota" what I'm talking about is actually just a number, eventually assigned with some unit. It could be a static limit on a specific resource like number of VMs or the amount of memory or disk space, or it could be something different like computing performance or even something like a currency at the longer term<br>
<br>
- What is the right place to store such "groups" or "roles" ? What do people think ?<br>
<br>
We are currently only interested in limit settings for Nova. The described ideas could be implemented as part of Nova, or as an entirely independent external tool (which might be incorporated later). IMO the latter approach has some advantages but I'd like to hear peoples opinion about this.<br>
</blockquote><div><br></div><div>I think this should be directly in nova.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<br>
We'll have some man power available to work on the design and the implementation of this so I'd expect to see some rapid progress if everbody agrees that this is a useful thing to do.<br></blockquote><div><br></div>
<div><br></div><div>Great!</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<br>
Thanks a lot for your comments/opinions!<br>
<br>
Kind regards,<br>
Ulrich<br>
<br>
<br>
______________________________<u></u>_________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.<u></u>org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/<u></u>cgi-bin/mailman/listinfo/<u></u>openstack-dev</a><br>
</blockquote></div><br></div></div>