On 02/14/2015 08:25 AM, Alex Xu wrote: > > > 2015-02-14 1:41 GMT+08:00 Nikola Đipanov <ndipa...@redhat.com > <mailto:ndipa...@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-requ...@lists.openstack.org?subject:unsubscribe > <http://openstack-dev-requ...@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-requ...@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-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev