Open Stack

On 02/14/2015 08:25 AM, Alex Xu wrote:
> 
> 
> 2015-02-14 1:41 GMT+08:00 Nikola Đipanov <ndipanov at redhat.com
> <mailto:ndipanov at redhat.com>>:
> 
>     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.
> 
> 
> 
> Agree with Nikola, the claim already checking that. And instance booting
> must be failed if there isn't pci device. But I still think it should go
> through the filters, because in the future we may move the claim into
> the scheduler. And we needn't any new options, I didn't see there is any
> behavior changed.
> 

I think that it's not as simple as just re-running all the filters. When
we want to force a host - there are certain things we may want to
disregard (like aggregates? affinity?) that the admin de-facto overrides
by saying they want a specific host, and there are things we definitely
need to re-run to set the limits and for the request to even make sense
(like NUMA, PCI, maybe some others).

So what I am thinking is that we need a subset of filters that we flag
as - "we need to re-run this even for force-host", and then run them on
every request.

thoughts?

N.

> 
> 
>     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.
> 
> 
>     __________________________________________________________________________
>     OpenStack Development Mailing List (not for usage questions)
>     Unsubscribe:
>     OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>     <http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe>
>     http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 
> 
> 
> 
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>