Open Stack

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.momo at gmail.com<mailto:chenrui.momo at gmail.com>>
Reply-To: OpenStack List <openstack-dev at lists.openstack.org<mailto:openstack-dev at lists.openstack.org>>
Date: Thursday, February 12, 2015 at 1:51 PM
To: OpenStack List <openstack-dev at lists.openstack.org<mailto:openstack-dev at 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 <sbauza at redhat.com<mailto:sbauza at 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-request at lists.openstack.org?subject:unsubscribe<mailto:OpenStack-dev-request at 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-request at lists.openstack.org?subject:unsubscribe<http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150212/d16abf47/attachment.html>