2015-02-14 1:41 GMT+08:00 Nikola Đipanov <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. > > 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://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