Open Stack

On 07/14/2014 12:10 PM, Jay Pipes wrote:
> On 07/14/2014 10:16 AM, Sylvain Bauza wrote:

>> From an operator perspective, people waited so long for having a
>> scheduler doing "scheduling" and not only "resource placement".
>
> Could you elaborate a bit here? What operators are begging for the
> scheduler to do more than resource placement? And if they are begging
> for this, what use cases are they trying to address?

I'm curious about this as well, what more than resource placement 
*should* the scheduler handle?

On the other hand, I *do* see a usecase for a more holistic scheduler 
that can take into account a whole group of resources at once (multiple 
instances, volumes, networks, etc. with various constraints on them, 
combined with things like server groups and host aggregates).

In a simple scenario, suppose a compute node fails.  I want to evacuate 
all the instances that had been on that compute node, but ideally I'd 
like the scheduler to look at all the instances simultaneously to try to 
place them...if it does them one at a time it might make a decision that 
doesn't use resources in an optimal way, possibly even resulting in the 
failure of one or more evacuations even though there is technically 
sufficient room in the cluster for all instances.

Alternately, suppose I have a group of instances that really want to be 
placed on the same physical network segment.  (For low latency, maybe.)

Lastly, I think that any information that fed into the original 
scheduler decision should be preserved for use by subsequent scheduling 
operations (migration, evacuation, etc.)  This includes stuff like 
image/flavor metadata, boot-time scheduler hints, etc.

Chris