Comment 14 for bug 1790204

Another issue with the approach in comment 9 is that we need to get alternative hosts from the scheduler in case the resize to the same host fails (assuming there would be alternative hosts).

So I think the flow would be something like this in conductor:

1. Are we doing a resize (based on Migration.migration_type) and if so, are we allowed to resize to the same host? We determine the latter from the RequestSpec.ignore_hosts field which is populated by the API if we can't do a resize to the same host:

https://github.com/openstack/nova/blob/f58cdcd58dc555b5b8635907987510f4970eae58/nova/compute/api.py#L3552

2. If the conditions in #1 are True, then we get the max of the allocations for the resources in the old and new flavor and try to PUT /allocations/{consumer_id} for the current instance.node compute node provider.

2a. If that PUT allocations works, then we check if we can get alternates (based on the max_attempts config) from the scheduler (and need to adjust the RequestSpec to ignore the host we already claimed resources for). This could result in NoValidHost if there are no more hosts available like in a small edge site and then we just don't have any alternates. Also in this case we would not swap the existing instance old_flavor allocations to the migration record, the instance would continue to contain the max() allocations for the old/new flavor on the same host. This would have implications for the revert allocations code in the compute service which expects there to be allocations on the migration record (maybe fixed here though? https://review.openstack.org/#/c/636412/) and would also have implications for rescheduling if the same-host resize fails and we need to reschedule to an alternate, in that case we need to swap the allocations (but conductor already does that it looks like, so maybe that's not an issue).

2b. If the PUT allocation fails, then we know we can't resize to that host and just add it to the RequestSpec.ignore_hosts field when we call the scheduler (we might not even need to do that since the scheduler would sum the old/new flavor and the allocations will fail for that host).

One issue with doing this and bypassing the scheduler for the same host would be anything in the new flavor that is not accounted for in placement, like NUMA or PCI requests, could fail during the resize_claim on the compute whereas they could have failed earlier during scheduling, but maybe that's a trade-off we have to live with for the time being.

--

Alternatives to this are simply drop that "double up" code in the scheduler and always claim using the new flavor allocations but at this point I'm not even sure if _move_operation_alloc_request does anything because since Queens we have moved the source node allocations to the migration record and the instance, during scheduling to a dest host, does not have allocations, meaning we could still fail the claim since the migration (old_flavor) + instance (new_flavor) on the same host is a sum and could fail.