Open Stack

On 07/19/2017 12:35 PM, Chris Friesen wrote:
> On 07/12/2017 06:57 PM, Jay Pipes wrote:
>> On 07/04/2017 05:21 AM, Kekane, Abhishek wrote:
>>> Hi operators,
>>>
>>> I want to know how evacuation of resized instances is handled in real
>>> environment.
>>> For example if the vm is in resized state and if the compute host on 
>>> which the
>>> vm is resized goes down, then how will operator evacuate the vm.
>>>
>>> One possible way is to reset that vm state to error and then evacuate 
>>> it to
>>> new compute host.
>>> Please refer below scenario for reference:
>>>
>>> Scenario:
>>> =========
>>>
>>> Pre-conditions:
>>> --------------------
>>> 1. Config option allow_resize_to_same_host is False.
>>> 2. Instance path is not mounted on shared storage.
>>> 3. Three compute nodes: "compute node A", "compute node B" and 
>>> "compute node C"
>>>
>>> Steps:
>>> --------
>>> 1. Boot an instance on "compute node A".
>>> 2. User tries to resize the newly created instance and nova-scheduler 
>>> selects
>>> "compute node B" as a destination node for resize.
>>>     In this case nova creates a instance directory on destination 
>>> "compute
>>> node B" and mark the instance directory which is present on the source
>>> "compute node A" as "*_resize".
>>>
>>> Note that the resize operation is yet not confirmed and "compute node 
>>> B" goes
>>> down.
>>>
>>> 3. Reset instance state to ERROR as nova allows evacuation only if 
>>> instance
>>> state is 'ACTIVE', 'STOPPED' or 'ERROR'.
>>
>> I don't understand why you would do this, Abhishek. Why not REVERT the 
>> resize
>> operation (which would clean up the _resize directory and files on the 
>> original
>> host A) and then try the resize again?
> 
> Sorry for the delayed reply (just got back from vacation).  If the dest 
> compute node is dead, is it even possible to revert the resize?

Abhishek was describing compute node "B" going down, not the source "A", 
right?

-jay