Looking back at mitaka, the api creates the request spec, but doesn't send it to conductor.build_instances, that just builds it's own fake request spec to pass to the scheduler; conductor passes that fake reqspec down to compute, where it's ignored. There are no request_spec.save() calls in mitaka, but there is one in newton for resize:
So I wonder if this is what happened: built the server on host1, resized - failed on host2, rescheduled to host3, then tried to live migrate to host2 and that was kicked out because the request_spec.save() during the resize reschedule was persisted.
I can change the functional test to try that scenario.
Looking back at mitaka, the api creates the request spec, but doesn't send it to conductor. build_instances , that just builds it's own fake request spec to pass to the scheduler; conductor passes that fake reqspec down to compute, where it's ignored. There are no request_spec.save() calls in mitaka, but there is one in newton for resize:
https:/ /github. com/openstack/ nova/blob/ newton- eol/nova/ conductor/ manager. py#L287
So I wonder if this is what happened: built the server on host1, resized - failed on host2, rescheduled to host3, then tried to live migrate to host2 and that was kicked out because the request_spec.save() during the resize reschedule was persisted.
I can change the functional test to try that scenario.