[Openstack-operators] Quota Templates

Tim Bell Tim.Bell at cern.ch
Mon Apr 7 18:45:21 UTC 2014


We can add some more CERN brass for this scenario. We want to fill up workload spread across the maximum number of hypervisors (don't overcommit unless you have to) but that means as you approach full, you can only give out small VMs that fit in the cracks.

In my ideal world, we would have a way of saying schedule for maximum distribution across hypervisors but make sure that there are X slots free for flavour A, Y slots free for flavour B etc for requests that exactly match that resource.

Given a 3-4 year purchasing cycle, the Thailand floods means HDDs were not available in volume and varying processor prices, we've got a large mixture of different configurations.

It's a really tough problem to do this at scale and quickly but I'd love to discuss/debate the options available to be able to turn the cloud efficiency up to 11 :)

Tim

From: Narayan Desai [mailto:narayan.desai at gmail.com]
Sent: 07 April 2014 20:33
To: Jay Pipes
Cc: openstack-operators at lists.openstack.org
Subject: Re: [Openstack-operators] Quota Templates

...

You must be using a much smarter openstack scheduler than I am. I'll agree in principle that this could be true, however, fragmentation avoidance is tricky problem, particularly when you have a big range of potential configuration. YOu can only imagine the sad trombone that played in my office the first time the scheduler placed an 8GB instance on a bigmem node, blocking that system's largest configuration from being usable. We've personally had a lot more luck partitioning resources, and picking a set of favorable resource combinations than letting the scheduler deal with it.

This is a great discussion. I think that we need more of this kind of thing on the operators list.
 -nld
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20140407/9c85a4a5/attachment.html>


More information about the OpenStack-operators mailing list