Difference between revisions of "StructuredStateManagement"
(→Connected blueprints) |
(→Summary) |
||
Line 1: | Line 1: | ||
== Summary == | == Summary == | ||
− | Move away from ad-hoc states and state transitions to a more concrete organized structured state management in nova. | + | Move away from ad-hoc states and state transitions to a more concrete organized structured state management in the various openstack projects (initial interests are in nova/heat). |
=== What problems does this solve === | === What problems does this solve === | ||
− | * Increases the [stability, extendability, reliability] of nova. | + | * Increases the [stability, extendability, reliability] of nova/heat. |
− | * Makes it easier to [debug, test, understand, verify, review] nova code. | + | * Makes it easier to [debug, test, understand, verify, review] nova/heat code. |
* Removes hard to discover state-transition dependencies and interactions with clearly defined state-transition dependencies and interactions. | * Removes hard to discover state-transition dependencies and interactions with clearly defined state-transition dependencies and interactions. | ||
* Ensures state transitions are done reliably and correctly by isolating those transitions to a single place. | * Ensures state transitions are done reliably and correctly by isolating those transitions to a single place. | ||
Line 25: | Line 25: | ||
# https://bugs.launchpad.net/nova/+bug/1082414 | # https://bugs.launchpad.net/nova/+bug/1082414 | ||
# ... | # ... | ||
− | |||
=== Connected blueprints === | === Connected blueprints === | ||
Line 43: | Line 42: | ||
=== Plan of record === | === Plan of record === | ||
− | # Create prototype. | + | # Create prototype |
− | # Get feedback from summit session. | + | ## Create library and use said library in nova for run_instance api in nova. |
− | # Get more feedback from email list & heat folks about common library. | + | # Get feedback others |
+ | ## Get feedback from summit session on said discussion and prototype. | ||
+ | ## Get more feedback from email list & heat folks about common library. | ||
# Adjust prototype as needed from feedback. | # Adjust prototype as needed from feedback. | ||
− | # Split prototype into small chunks. | + | # Split prototype+library into small chunks. |
# Adjust tests for each small chunks. | # Adjust tests for each small chunks. | ||
− | # Start to submit | + | # Start to submit chunks into http://review.openstack.org (disabling whole/pieces component until ready to turn on?). |
=== Prototype === | === Prototype === |
Revision as of 23:11, 24 April 2013
Contents
Summary
Move away from ad-hoc states and state transitions to a more concrete organized structured state management in the various openstack projects (initial interests are in nova/heat).
What problems does this solve
- Increases the [stability, extendability, reliability] of nova/heat.
- Makes it easier to [debug, test, understand, verify, review] nova/heat code.
- Removes hard to discover state-transition dependencies and interactions with clearly defined state-transition dependencies and interactions.
- Ensures state transitions are done reliably and correctly by isolating those transitions to a single place.
- Removes the need for periodic tasks to cleanup garbage left by nova's ad-hoc states.
- Fixes a variety of problems that previously had piecemeal like patches applied.
- Eliminates the inherent fragility of a ad-hoc workflow.
- Creates the path for smart resource scheduling.
- Makes it possible to do [resizing, live migration] in a more secure and manageable manner.
- Makes it possible to audit & track the state transitions performed on a given resource.
- Makes it possible for nova to have multi-stage booting where an instances and its dependent resources are first reserved, the resources configured, the instance configured, and then finally the instance is powered-on (thus completing the instance provisioning process).
- Addresses the underlying key point of http://www.slideshare.net/harlowja/nova-states-summit/9 where states will now be fully recovered from on cutting.
Issues that would likely not have happened with a better state management system
- https://blueprints.launchpad.net/nova/+spec/compute-instance-cleanup-service
- https://bugs.launchpad.net/nova/+bug/1050979
- https://bugs.launchpad.net/nova/+bug/1061024
- https://bugs.launchpad.net/nova/+bug/1082414
- ...
Connected blueprints
Requirements
https://etherpad.openstack.org/task-system
Discussions
https://etherpad.openstack.org/the-future-of-orch
Plan of record
- Create prototype
- Create library and use said library in nova for run_instance api in nova.
- Get feedback others
- Get feedback from summit session on said discussion and prototype.
- Get more feedback from email list & heat folks about common library.
- Adjust prototype as needed from feedback.
- Split prototype+library into small chunks.
- Adjust tests for each small chunks.
- Start to submit chunks into http://review.openstack.org (disabling whole/pieces component until ready to turn on?).
Prototype
https://github.com/Yahoo/NovaOrc
Design
Design details
In order to implement of this new orchestration layer the following key concepts must be built into the design from the start.
- A set of atomic tasks that can be organized into a workflow.
- Task resumption.
- Task rollback.
- Task tracking.
- Resource locking.
- Workflow sharding/ownership.
- Simplicity (allowing for extension and verifiability).
- Tolerant to upgrades.