Comment 5 for bug 1790204

Also, the hack idea I had in comment 1:

"One hacky way we could handle this is in conductor, after we've moved the instance allocations for the old_flavor to the migration record, if the selected host is the same host the instance is already one, we just fix the allocations so they are the max of the two flavors"

Doesn't really work for what I was thinking. I was thinking conductor could swap the allocations for the old flavor from the instance to the migration consumer, get the dest host from the scheduler (which would also create the allocations for the instance against the dest host using the new flavor), and then in conductor if we see that the selected host is the same host, we'd fix the allocations. However, fixing the allocations in conductor is too late if we've already failed with a NoValidHost because placement thinks there are no resources available...

So we either need to fix the allocations that we swap to the migration record *before* calling the scheduler to allocate for the new flavor, or somehow hack something into RequestSpec to tell the scheduler the actual resource amount we want to allocate for the instance.

Given I think the end result we want from the resize is that the new flavor allocations exist with the instance, we probably don't want to mess with those. So that leaves fixing the allocations we move to the migration record before calling the scheduler - but then we have to adjust those if we are not actually resizing to the same host...yuck.

For example, if we start with old flavor:

VCPU = 4, MEMORY_MB = 2048, DISK_GB = 20

And resize with new flavor:

VCPU = 2, MEMORY_MB = 4096, DISK_GB = 20

We want to end up with the max of those values allocated against the provider, so:

VCPU = 4, MEMORY_MB = 4096, DISK_GB = 20

And we want new flavor to be on the instance consumer, which leaves these amounts on the migration consumer before scheduling (max(old-new, 0)):

VCPU = 2, MEMORY_MB = 0, DISK_GB = 0

If the scheduler returns a host that is not the same host that the instance is on, then we need to fix the migration allocations back to the old_flavor (which is risky if something took that space in the meantime...).

So probably the grossest but safest way to fix this is at the point of claiming the dest host allocations for the instance with the new flavor, in the scheduler...which means passing something through on the request spec for that case to adjust the allocations if and only if the source and dest are the same provider.