<div dir="ltr">Append blueprint link:<div><a href="https://blueprints.launchpad.net/nova/+spec/verifiable-force-hosts">https://blueprints.launchpad.net/nova/+spec/verifiable-force-hosts</a><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">2015-02-13 10:48 GMT+08:00 Rui Chen <span dir="ltr"><<a href="mailto:chenrui.momo@gmail.com" target="_blank">chenrui.momo@gmail.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">I agree with you @Chris<div>'--force' flag is a good idea, it keep backward compatibility and flexibility.</div><div>We can select whether the filters was applied for force_hosts.</div><div>I will register blueprint to trace the feature.</div><div><br></div><div>The 'force_hosts' feature is so age-old that I don't know how many users had used it.</div><div>Like @Jay says. Removing it is once and for all idea, but I'm not sure that it's a suitable occasion.</div></div><div class="HOEnZb"><div class="h5"><div class="gmail_extra"><br><div class="gmail_quote">2015-02-12 23:10 GMT+08:00 Chris Friesen <span dir="ltr"><<a href="mailto:chris.friesen@windriver.com" target="_blank">chris.friesen@windriver.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span>On 02/12/2015 03:44 AM, Sylvain Bauza wrote:<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Any action done by the operator is always more important than what the Scheduler<br>
could decide. So, in an emergency situation, the operator wants to force a<br>
migration to an host, we need to accept it and do it, even if it doesn't match<br>
what the Scheduler could decide (and could violate any policy)<br>
<br>
That's a *force* action, so please leave the operator decide.<br>
</blockquote>
<br></span>
Are we suggesting that the operator would/should only ever specify a specific host if the situation is an emergency?<br>
<br>
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.<br>
<br>
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.<span><font color="#888888"><br>
<br>
Chris</font></span><div><div><br>
<br>
______________________________<u></u>______________________________<u></u>______________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" target="_blank">OpenStack-dev-request@lists.<u></u>openstack.org?subject:<u></u>unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/<u></u>cgi-bin/mailman/listinfo/<u></u>openstack-dev</a><br>
</div></div></blockquote></div><br></div>
</div></div></blockquote></div><br></div>