Comment 8 for bug 1790204

I was starting to hack up a solution where conductor would detect the possibility of doing a same-host resize and *not* swap the source node old_flavor allocations to the migration record, which I thought would then get us to the point where the scheduler calls the _move_operation_alloc_request method during claim_resources. However, we don't even get that far because the GET /allocation_candidates request to placement filters out the only host (in this case the provider has DISK_GB=1028 and that's also what is currently allocated to the server with the old_flavor, and even though the new_flavor disk size doesn't change, the scheduler is requesting 1028 more).

So clearly we have to do something before we ever call GET /allocation_candidates to either (1) change the amount of resource we request, or (2) free up resources on the source host before calling the scheduler.

1. For the former, I think that would mean mutating the RequestSpec.flavor to be the max of the old/new flavor values, so using the example from comment 5 that would be:

VCPU = 2, MEMORY_MB = 0, DISK_GB = 0

However, if the scheduler picks a host that is *not* the same host, we'd be claiming the wrong thing on that host. So that won't work, unless we stash off that override in the request spec and *only* use it if we determine, from the scheduler before doing the claim, that we're going to be claiming on the same host. That's pretty gross.

2. For the latter, conductor could drop the old_flavor allocations held by the server on the source compute node before calling the scheduler. Then once we get the selected destination, if it's the same host, we're good. If it's *not* the same host, we need to put the old_flavor allocations on the source host, tracked by the migration record. This could fail if something claimed resources on the source node while scheduling the resize, but that seems like a pretty small window to happen. Additionally, if we did fail to re-claim the old_flavor resources on the source host, we could potentially ignore that host (same host) and pick the next alternate (which we'd know isn't the same host). If the only host available was the same host, then I guess we lose and just have to fail the resize until more resources are freed up - which seems natural and OK.

Option 2 there sounds pretty good, because we:

a) would only be claiming new_flavor values on the dest host (which is already what we do today)
b) would be able to re-claim the allocations for the old flavor potentially if the scheduler picked another host (keep our spot on the source host)
c) if we are resizing to the same host, and the migration record doesn't hold allocations, I believe the compute code before Stein will still handle that case gracefully and not try to swap anything back from the migration to the instance on revert (or failure):

https://github.com/openstack/nova/blob/bc0a5d0355311641daa87b46e311ae101f1817ad/nova/compute/manager.py#L4189

Things might get hairy with reschedules so that might need to be dealt with separately in conductor but we'll see - need to add tests for those wrinkles (selected host is same host and resize fails so we reschedule to another host, are allocations OK, and vice-versa where the alternate is the same host).