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.b...@nttdata.com | VOIP. 8833.8395I | nttdata.com/americas NTT DATA, Inc. Consulting | Digital | Managed Services | Industry Solutions -----Original Message----- From: Jay Pipes [mailto:jaypi...@gmail.com] Sent: Wednesday, July 19, 2017 10:27 PM To: openstack-operators@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@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. _______________________________________________ OpenStack-operators mailing list OpenStack-operators@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
