Improve VM State Management to constrain state transitions

Registered by Phil Day

Current checks on valid state transitions are limited to a few cases, leading to multiple opportunities for non-deterministic behavior. In addition some long running tasks can lead to odd behavior – for example a VM in the building state can spend a long time in image download, be terminated, and when the image download completes go ahead and launch the VM.

This blueprint would constrain the valid state transitions to a limited subset, and ensure that the remaining transitions lead to consistent and deterministic behavior.

Blueprint information

Status:
Complete
Approver:
Vish Ishaya
Priority:
Essential
Drafter:
Nova Orchestration Team
Direction:
Approved
Assignee:
HP Nova Contributors
Definition:
Approved
Series goal:
Accepted for essex
Implementation:
Implemented
Milestone target:
milestone icon 2012.1
Started by
Thierry Carrez
Completed by
Thierry Carrez

Related branches

Sprints

Whiteboard

I suggest a quick pass through the states to fix any glaring bugs, and saving the majority of the changes for the orchestration components. --Vish

We have this pretty much already coded against our Diablo.Final version, and I think it stands independent from everything else I've understood so far about orchestration (it's more a gate on what operations can be performed against an individual VM's state) - so I'd like to be able to rebase and contribute seperalty from other orchestartion work. --Phil

Phil. Can you update your chagnes and propose to trunk so we can get them in by essex-2? --Vish

Hi Vish - it looks as if there have been a few new actions added to trunk since we developed this (we're still working on a Diablo code base), so since we're not familiar with what those actions do (soft_delete, force_delete, restore, backup) or what the right set of actions should be for a couple of new states (rebooting_hard, forcing_off) what we propose to do is to rebase our changes onto trunk as they are and make that available for review, and let the changes required for these additional actions/states come out in the review. We should get the first candidate up in the next day or two - does that work ?

Sounds Good. --Vish

Gerrit topic: https://review.openstack.org/#q,topic:bp/nova-vm-state-management,n,z

Addressed by: https://review.openstack.org/1695
    Vm state management, timeouts and error states

(?)

Work Items

This blueprint contains Public information 
Everyone can see this information.