Open Stack

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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20131226/a203927c/attachment.html>