Comment 9 for bug 1460577

I had a look through the code because I was curious, and it seems to me we might be able to provide the ability to start an unconfirmed/unreverted resized instance by (1) allowing 'start' from the RESIZED state and (2) restoring the vm_state.RESIZED and task_state None to the instance after the 'start' completes, based on whether the instance has a migration_context indicating a resize-in-progress.

I was thinking the main challenge with this ask was avoiding the wipeout of the resize-related states on the instance after start completes, but we can figure out if the instance was in the middle of a resize by checking if there's a migration_context.

If the instance is in the middle of a resize, its migration_context will have the migration_id and we could lookup the Migration. Then, if the migration.status = 'finished' and migration.migration_type = 'resize', we know to set the vm_state to RESIZED and task_state to None after the 'start' is completed.

I think the only concern left is: would/could anything bad happen if a user attempts to 'start' a RESIZED instance that is already powered on? From the libvirt driver code, doing this would initiate a hard reboot. For other drivers, it depends on their power_on code. I think it might be bad/unexpected if we hard reboot a user's instance if they 'start' a powered on instance in state RESIZED (and for example, didn't realize the instance was already powered on or otherwise sent the request by mistake). But we can't check the power state from compute/api -- we rely on vm_state.STOPPED for that.

(Later) Actually we do have an Instance.power_state attribute we could look at in the compute/api for 'start'. So if vm_state.RESIZED then check Instance.power_state and if it's not power_state.SHUTDOWN, reject the request with a 409.

This is all a bit complex in order to allow 'start' and preserve instance states for a RESIZED instance, so I'm not sure how important this is to operators and whether it's worth the effort and complexity to implement.

On the other hand, we do allow users to 'resize' a STOPPED instance, yet they are disallowed from 'start'ing it to assess whether the resize went smoothly. I guess the workaround for that would be the 'revert' the resize, 'start' the instance, and then 'resize' it again.