Open Stack

On Thu, Nov 05, 2015 at 09:33:37AM -0500, Andrew Laski wrote:

:Can you be a little more specific on what API difference is important
:to you?  There are two differences currently between migrate and
:resize in the API:
:
:1. There is a different policy check, but this only really protects
:the next bit.
:
:2. Resize passes in a new flavor and migration does not.
:
:Both actions result in an instance being scheduled to a new host.  If
:they were consolidated into a single action with a policy check to
:enforce that users specified a new flavor and admins could leave that
:off would that be problematic for you?

My typical use is live-migration (perhaps that is yet another code
path?) which involves:

3. specify the host to migrate to

This is what I really want to protect.

my use case if it helps:

The reason I want to specify the host (or if I could even better a
host aggregaate) is that I use 'cpu_mode=host-passthrough' and have a
few generations of hardware (and my instance types are not constrained
to a particular generation which I realize is an option as we do that
for other purposes) so left to the scheduler it might try to
live-migrate to an older cpu generation which would fail so we'r
ecurrently using human intelligence to try to migrate to same
generation and if that's full move newer.

This is an uncommon but important procedure mostly used for updates that
require hypervisor reboot in which we roll everything from node-0 to
node-N, update 0 then roll node-1 to node0 etc ...

If I could constrain migration by host aggregate in ways that didn't
map to instance type metadata constraints that would simplify this,
but the current situation is adequate for me.

This isn't an issue with non-live migration or rezize neither of which
requite CPU consistency.

-Jon