Comment 1 for bug 1790204

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 - but we'd need to sort out if we still use 2 consumers or only 1 - it might make sense to only have the instance consumer for the same-host resize case, but there is logic in the nova-compute service since queens that expects the source node allocations to be tracked by the migration record consumer, so those would have to be audited so they don't blow up now depending on what conductor does.

Another wrinkle that we have to worry about is resize can reschedule if the selected host fails the resize. So we could have a case where the scheduler picks 3 hosts:

1. first selected host is the same host, but fails, so we reschedule to host 2
2. second host fails, we reschedule to host 3
3. the resize passes on the 3rd host (2nd alternate)

In those cases, the alternative hosts are *not* the same host so how would we deal with the allocations then because the old flavor allocations still need to be on the source host and the new flavor allocations need to be on the destination host.