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.schwicker...@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@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >
_______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev