[openstack-dev] [Openstack] Quota delegation tool (for nova) ?

Dina Belova dbelova at mirantis.com
Thu Dec 26 19:51:05 UTC 2013

That quota staff has been following me from summit where we discussed that
with Tim. Also, Ulrich, Sylvain is right - speaking about one piece of cake
for one customer, our Climate (Reservation-as-a-Service) might help that.
That piece might be some amount of hosts with specific (customer specific)
characteristics, or just some already created and reserved virtual
capacity measured in certain amount of VMs, volumes, etc.

I'll be here in mailing list (and, probably, on our IRC channel
#openstack-climate) during all holidays, so you are welcome! Now I'm
working on better documentation for Climate just to give link and that's
it, but now I may only explain that by mails and so on :)

[Climate Launchpad] https://launchpad.net/climate
[Hosts Reservation BP]
[Climate wiki (not compete one)]

On Thu, Dec 26, 2013 at 9:44 PM, Sylvain Bauza <sylvain.bauza at gmail.com>wrote:

> Hi Ulrich,
> I already discussed with Tim during last Swiss meetup at CERN about how
> Climate could maybe help you on your use cases. There are still many things
> to discuss and a demo to run out so we could see if it match your needs.
> Basically, Climate is a new Stackforge project planning to implement
> resource reservations in OpenStack, including but not exhaustively Nova
> instances or nova-compute nodes. Resources can be allocated to either full
> tenants or to a specific user and can be provisioned now or in a certain
> period of time.
> About quotas, that's something not yet planned but kind of nice feature to
> have.
> Sorry but as I'm being in vacations, I don't have way to give you more
> inputs on this (typing from my very limited phone...) but should you be
> interested in, just give a shot and search on ML, you'll find previous
> pointers.
> -Sylvain
>  Le 26 déc. 2013 08:04, "Ulrich Schwickerath" <ulrich.schwickerath at cern.ch>
> a écrit :
> Dear all,
>> 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.
>> 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
>> infrastructure. Our main customers are the LHC experiments, which by
>> themselves are fairly large dynamic organizations with complex internal
>> structures, with specific requirements
>> 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.
>> 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":
>> - The main resource manager determines the fractions of the resources for
>> each customer
>> - He allocates a quota to each customer by giving it to a "computing
>> coordinater" which is nominated by the customer
>> - 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
>> and so on.
>> 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:
>> - There are people with different roles in this game:
>>   +- the main resource manager role is a super user role which can but
>> does not have to be identical to the cloud manager.
>>      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
>>      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
>>  +- 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
>>  +- a normal user: persons with this role can only consume resources
>> - 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.
>> - 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
>> - What is the right place to store such "groups" or "roles" ? What do
>> people think ?
>> 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.
>> 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.
>> Thanks a lot for your comments/opinions!
>> Kind regards,
>> Ulrich
>> _______________________________________________
>> OpenStack-dev mailing list
>> OpenStack-dev at lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Best regards,

Dina Belova

Software Engineer

Mirantis Inc.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20131226/0f2b5f43/attachment.html>

More information about the OpenStack-dev mailing list