filters should be applied to the list of hosts that are in ‘force_hosts’.
Yes, @Gray, it's my point. Operator can live-migrate a instance to a specified host and skip filters, it's apposite and important, I agree with you. But when we boot instance, we always want to launch a instance successfully or get a clear failure reason, if the filters are applied for the force host, operator maybe find out that he is doing something wrong at earlier time. For example, he couldn't boot a pci instance on a force host that don't own pci device. and I don't think 'force_hosts' is operator action, the default value is 'is_admin:True' in policy.json, but in some case the value may be changed so that the regular user can boot instance on specified host. 2015-02-12 17:44 GMT+08:00 Sylvain Bauza <sba...@redhat.com>: > > Le 12/02/2015 10:05, Rui Chen a écrit : > > Hi: > > If we boot instance with 'force_hosts', the force host will skip all > filters, looks like that it's intentional logic, but I don't know the > reason. > > I'm not sure that the skipping logic is apposite, I think we should > remove the skipping logic, and the 'force_hosts' should work with the > scheduler, test whether the force host is appropriate ASAP. Skipping > filters and postponing the booting failure to nova-compute is not advisable. > > On the other side, more and more options had been added into flavor, > like NUMA, cpu pinning, pci and so on, forcing a suitable host is more and > more difficult. > > > 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. > > -Sylvain > > > > Best Regards. > > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: > openstack-dev-requ...@lists.openstack.org?subject:unsubscribehttp://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