I'm not sure how Climate would map to the non-predictable nature of the 
workload. I had understood Climate as providing a booking system to reserve 
resources in the future (which is a valuable use case but not quite the problem 
Ulrich is describing of delegation of quota).

Looking at https://blueprints.launchpad.net/nova/+spec/domain-quota-driver, it 
appears that there is a quota driver using Domains being developed for Icehouse 
in Nova. I don't know if it completely covers the use case (i.e. quotas on both 
projects and domains), but if this is the case, the delegation might be handled 
with the domain/project structure and an appropriate policy definition 
(http://docs.openstack.org/trunk/openstack-ops/content/customize_auth.html) 
where the domain manager has the rights to modify the quota of the projects as 
well as the project manager.

With the groups functions mapping onto roles, I think this functionality could 
be built using the domain quota driver (or a derivative of it), policies and 
groups and allow other kinds of delegation in addition to quotas (such as 
shared image upload).

Tim


On 26 Dec 2013, at 20:51, Dina Belova 
<dbel...@mirantis.com<mailto:dbel...@mirantis.com>> wrote:

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] 
https://wiki.openstack.org/wiki/Blueprint-nova-planned-resource-reservation-api
[Climate wiki (not compete one)] 
https://wiki.openstack.org/wiki/Resource-reservation-service


On Thu, Dec 26, 2013 at 9:44 PM, Sylvain Bauza 
<sylvain.ba...@gmail.com<mailto:sylvain.ba...@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.schwicker...@cern.ch<mailto: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<mailto:OpenStack-dev@lists.openstack.org>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org<mailto:OpenStack-dev@lists.openstack.org>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev




--
Best regards,
Dina Belova
Software Engineer
Mirantis Inc.
_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org<mailto: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

Reply via email to