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].
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.
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].
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 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.
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].
[1] https://bugs.launchpad.net/nova/+bug/1712008
[2] https://bugs.launchpad.net/nova/+bug/1713786
[3] https://bugs.launchpad.net/nova/+bug/1427772
[4] https://review.openstack.org/#/c/489031/
[5]
http://lists.openstack.org/pipermail/openstack-dev/2017-August/121342.html
[6]
https://specs.openstack.org/openstack/nova-specs/specs/mitaka/implemented/check-destination-on-migrations.html
[7] https://bugs.launchpad.net/nova/+bug/1675791
[8] https://bugs.launchpad.net/nova/+bug/1627694
[9] https://bugs.launchpad.net/nova/+bug/1547142
--
Thanks,
Matt
_______________________________________________
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
