I understand the fact that an opertaor can and should be able to place the VM where she/he wants. The VM should just adhere to the scheduling constraints :) (which are defined in the filters) :)
From: Rui Chen <chenrui.m...@gmail.com<mailto:chenrui.m...@gmail.com>> Reply-To: OpenStack List <openstack-dev@lists.openstack.org<mailto:openstack-dev@lists.openstack.org>> Date: Thursday, February 12, 2015 at 1:51 PM To: OpenStack List <openstack-dev@lists.openstack.org<mailto:openstack-dev@lists.openstack.org>> Subject: Re: [openstack-dev] [nova] Question about force_host skip filters 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<mailto: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:unsubscribe<mailto: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://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
