<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Aug 30, 2017 at 5:09 PM, Matt Riedemann <span dir="ltr"><<a href="mailto:mriedemos@gmail.com" target="_blank">mriedemos@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Given the recent bugs [1][2] due to the force flag in the live migrate and evacuate APIs related to Placement, and some other long standing bugs about bypassing the scheduler [3], I don't think we should add the force option to the cold migrate API, as (re-)proposed in Takashi's cold migrate spec here [4].<br>
<br>
I'm fine with being able to specify a host during cold migrate/resize, but I think the specified host should be validated by the scheduler (and placement) so that the instance can actually move to that specified destination host.<br>
<br>
Since we've built more logic into the scheduler in Pike for integration with Placement, bypassing that gets us into maintenance issues with having to duplicate code throughout conductor and just in general, seems like a bad idea to force a host and bypass the scheduler and potentially break the instance. Not to mention the complicated logic of passing the host through from the API to conductor to the scheduler is it's own maintenance problem [5].<br>
<br>
Looking back at when the force flag was added to the APIs, it was from this spec [6]. Reading that, before that microversion if a host was specified we'd bypass the scheduler, so the force flag was really just there for backward compatibility </blockquote><div><br></div><div>Indeed. That said, I've heard some ops wanting to migrate instances to computes where resources were not possibly enough to accept the instance but where it's preferred to have performance problems than just stopped instances.<br></div><div>If you think about the move operations using the force flag (evacuate and live-migrate), those were used by operators when they had a problem with a compute node and they wanted to *evacuate* very quickly instances.<br><br><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">I guess in case you wanted the option to break the instance or your deployment. :) Otherwise after that microversion if you specify a host but not the force flag, then we validate the specified host via the scheduler first. Given this, and the fact we don't have any backward compatibility to maintain with specifying a host for cold migrate, I don't think we need to add a force flag for it, unless people really love that option on the live migrate and evacuate APIs, but it just seems overly dangerous to me.<br></blockquote><div><br></div><div>While I understand operators wanting to *evacuate* instances (or rebuilding them by using the evacuation API) in case they see problems with hosts, I don't see why we should need to have a "force" flag for a cold migration if you're passing a target.<br></div><div>Say : <br></div><div> - either your compute node is down and then you need to recreate your customers' instances very quickly : then you call "nova evacuate".<br></div><div> - or your compute node is still alive but you want to migrate quickly without telling your customers : then you use "nova live-migrate".<br><br></div><div>I don't see cases where operators (because passing a target requires you to be an admin)  would like to cold migrate instances for their customers without communicating them a specific timeline for the move operation and so quickly that it would require to use a force flag to bypass the scheduler.<br></div><div>Maybe I'm wrong but I'm fine with asking Takashi to not add the force flag in his implementation for the cold migration API and wait for people wanting to have that flag to propose a specific specification that would describe the use-case.<br><br></div><div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
Finally, if one is going to make the argument, "but this would be consistent with the live migrate and evacuate APIs", I can also point out that we don't allow you to specify a host (forced or not) during unshelve of a shelved offloaded instance - which is basically a move (new build on a new host chosen by the scheduler). I'm not advocating that we make unshelve more complicated though, because that's already broken in several known ways [7][8][9].<br></blockquote><div><br></div><div>Well, we don't have consistent APIs anyway. If you think about all the move operations plus the boot request itself, each of them is *already* very different from the other from an API perspective. Yay.<br><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
[1] <a href="https://bugs.launchpad.net/nova/+bug/1712008" rel="noreferrer" target="_blank">https://bugs.launchpad.net/nov<wbr>a/+bug/1712008</a><br>
[2] <a href="https://bugs.launchpad.net/nova/+bug/1713786" rel="noreferrer" target="_blank">https://bugs.launchpad.net/nov<wbr>a/+bug/1713786</a><br>
[3] <a href="https://bugs.launchpad.net/nova/+bug/1427772" rel="noreferrer" target="_blank">https://bugs.launchpad.net/nov<wbr>a/+bug/1427772</a><br>
[4] <a href="https://review.openstack.org/#/c/489031/" rel="noreferrer" target="_blank">https://review.openstack.org/#<wbr>/c/489031/</a><br>
[5] <a href="http://lists.openstack.org/pipermail/openstack-dev/2017-August/121342.html" rel="noreferrer" target="_blank">http://lists.openstack.org/pip<wbr>ermail/openstack-dev/2017-Augu<wbr>st/121342.html</a><br>
[6] <a href="https://specs.openstack.org/openstack/nova-specs/specs/mitaka/implemented/check-destination-on-migrations.html" rel="noreferrer" target="_blank">https://specs.openstack.org/op<wbr>enstack/nova-specs/specs/mitak<wbr>a/implemented/check-destinatio<wbr>n-on-migrations.html</a><br>
[7] <a href="https://bugs.launchpad.net/nova/+bug/1675791" rel="noreferrer" target="_blank">https://bugs.launchpad.net/nov<wbr>a/+bug/1675791</a><br>
[8] <a href="https://bugs.launchpad.net/nova/+bug/1627694" rel="noreferrer" target="_blank">https://bugs.launchpad.net/nov<wbr>a/+bug/1627694</a><br>
[9] <a href="https://bugs.launchpad.net/nova/+bug/1547142" rel="noreferrer" target="_blank">https://bugs.launchpad.net/nov<wbr>a/+bug/1547142</a><span class="gmail-HOEnZb"><font color="#888888"><br>
<br>
-- <br>
<br>
Thanks,<br>
<br>
Matt<br>
<br>
______________________________<wbr>______________________________<wbr>______________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.op<wbr>enstack.org?subject:unsubscrib<wbr>e</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi<wbr>-bin/mailman/listinfo/openstac<wbr>k-dev</a><br>
</font></span></blockquote></div><br></div></div>