<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">2015-02-14 1:41 GMT+08:00 Nikola Đipanov <span dir="ltr"><<a href="mailto:ndipanov@redhat.com" target="_blank">ndipanov@redhat.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span class="">On 02/12/2015 04:10 PM, Chris Friesen wrote:<br>
> On 02/12/2015 03:44 AM, Sylvain Bauza wrote:<br>
><br>
>> Any action done by the operator is always more important than what the<br>
>> Scheduler<br>
>> could decide. So, in an emergency situation, the operator wants to<br>
>> force a<br>
>> migration to an host, we need to accept it and do it, even if it<br>
>> 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>
><br>
> Are we suggesting that the operator would/should only ever specify a<br>
> specific host if the situation is an emergency?<br>
><br>
> If not, then perhaps it would make sense to have it go through the<br>
> scheduler filters even if a host is specified.  We could then have a<br>
> "--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)<br>
> where it really makes no sense to try and run an instance on a compute<br>
> node that wouldn't pass the scheduler filters.  Maybe it would make the<br>
> most sense to specify a list of which filters to override while still<br>
> using the others.<br>
><br>
<br>
</span>Actually this kind of already happens on the compute node when doing<br>
claims. Even if we do force the host, the claim will fail on the compute<br>
node and we will end up with a consistent scheduling.<br></blockquote><div><br></div><div><br></div><div>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.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<br>
This sadly breaks down for stuff that needs to use limits, as limits<br>
won't be set by the filters.<br>
<br>
Jay had a BP before to move limits onto compute nodes, which would solve<br>
this issue, as you would not need to run the filters at all - all the<br>
stuff would be known to the compute host that could then easily say<br>
"nice of you to want this here, but it ain't happening".<br>
<br>
It will also likely need a check in the retry logic to make sure we<br>
don't hit the host 'retry' number of times.<br>
<span class=""><font color="#888888"><br>
N.<br>
</font></span><div class=""><div class="h5"><br>
<br>
__________________________________________________________________________<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.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</div></div></blockquote></div><br></div></div>