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: https://blueprints.launchpad.net/nova/+spec/per-user-quotas https://blueprints.launchpad.net/nova/+spec/multiple-level-user-quota-management 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.
Regard, Yingjun 在 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 OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
