[Openstack-operators] [openstack-dev] [masakari][nova] Allow evacuation of instances in resized state

Bhor, Dinesh Dinesh.Bhor at nttdata.com
Fri Jul 21 06:35:54 UTC 2017


Hi all,

I have tested the scenario Jay has requested.

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] create one instance on "compute node A".
2] resize it, it will go to "compute node B"(make "compute node C" compute service down so that nova will select "compute node B" for resize)

Note that the resize operation is not yet confirmed and "compute node B" goes down.

3] Make "compute node B" down and "compute node C" UP
4] Try to revert the resize

Observation:
Resize is not reverted.

Instance remains in REVERT_RESIZE vm_state until the "compute node B" compute service becomes UP.
After the "compute node B" compute service is UP it is reverted back on "compute node A". 

Instance states:
vm_state: REVERT_RESIZE
task_state: resize_reverting
power_state: Running


Thanks and Regards,
Dinesh Bhor | App. Software Dev. Cnslt.
dinesh.bhor at nttdata.com | VOIP. 8833.8395I | nttdata.com/americas
NTT DATA, Inc.
Consulting | Digital | Managed Services | Industry Solutions



-----Original Message-----
From: Jay Pipes [mailto:jaypipes at gmail.com] 
Sent: Wednesday, July 19, 2017 10:27 PM
To: openstack-operators at lists.openstack.org
Subject: Re: [Openstack-operators] [openstack-dev] [masakari][nova] Allow evacuation of instances in resized state

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

_______________________________________________
OpenStack-operators mailing list
OpenStack-operators at lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

______________________________________________________________________
Disclaimer: This email and any attachments are sent in strictest confidence
for the sole use of the addressee and may contain legally privileged,
confidential, and proprietary data. If you are not the intended recipient,
please advise the sender by replying promptly to this email and then delete
and destroy this email and any attachments without any further use, copying
or forwarding.


More information about the OpenStack-operators mailing list