Open Stack

On 02/12/2015 04:10 PM, Chris Friesen wrote:
> On 02/12/2015 03:44 AM, Sylvain Bauza wrote:
> 
>> Any action done by the operator is always more important than what the
>> Scheduler
>> could decide. So, in an emergency situation, the operator wants to
>> force a
>> migration to an host, we need to accept it and do it, even if it
>> doesn't match
>> what the Scheduler could decide (and could violate any policy)
>>
>> That's a *force* action, so please leave the operator decide.
> 
> Are we suggesting that the operator would/should only ever specify a
> specific host if the situation is an emergency?
> 
> If not, then perhaps it would make sense to have it go through the
> scheduler filters even if a host is specified.  We could then have a
> "--force" flag that would proceed anyways even if the filters don't match.
> 
> There are some cases (provider networks or PCI passthrough for example)
> where it really makes no sense to try and run an instance on a compute
> node that wouldn't pass the scheduler filters.  Maybe it would make the
> most sense to specify a list of which filters to override while still
> using the others.
> 

Actually this kind of already happens on the compute node when doing
claims. Even if we do force the host, the claim will fail on the compute
node and we will end up with a consistent scheduling.

This sadly breaks down for stuff that needs to use limits, as limits
won't be set by the filters.

Jay had a BP before to move limits onto compute nodes, which would solve
this issue, as you would not need to run the filters at all - all the
stuff would be known to the compute host that could then easily say
"nice of you to want this here, but it ain't happening".

It will also likely need a check in the retry logic to make sure we
don't hit the host 'retry' number of times.

N.