Good idea, it really makes sense. Just like the option 'run_filter_once_per_request' does.
2015-02-16 15:17 GMT+08:00 Nikola Đipanov <ndipa...@redhat.com>: > 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 -- Regards! ----------------------------------- Lingxian Kong __________________________________________________________________________ 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