Hi, Ulrich

Currently nova has per-project-user quota support, which was implemented in 
Havana. We also got some similar thoughts about quota management, here is some 
related blueprints: 
and there are also some discussions to store quota data in keystone you may be 
interested, https://lists.launchpad.net/openstack/msg11558.html
we did not get much progress about multiple level user quota management for 
now, so i would be glad if you could move this on.


在 2013年12月26日,下午3:00,Ulrich Schwickerath <ulrich.schwicker...@cern.ch> 写道:

> 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

Reply via email to