Difference between revisions of "StructuredStateManagement"
(→Design) |
(→High availability) |
||
Line 28: | Line 28: | ||
=== High availability === | === High availability === | ||
+ | |||
+ | In order to achieve high availability of this new orchestration layer the following key concepts must be build into the design the start. | ||
+ | |||
+ | # A set of '''atomic''' tasks that can be organized into a workflow. | ||
+ | # Task resumption and rollback. | ||
+ | # Task tracking. | ||
+ | # Resource locking. | ||
+ | # Workflow sharding. | ||
+ | # Simplicity (allowing for extension and verifiability). |
Revision as of 21:18, 22 April 2013
Contents
Summary
Move away from ad-hoc states and state transitions to a more concrete organized structured state management in nova.
Requirements
https://etherpad.openstack.org/task-system
Discussions
https://etherpad.openstack.org/the-future-of-orch
Plan of record
- Create prototype.
- Get feedback from summit session.
- Get more feedback from email list & heat folks about common library.
- Adjust prototype as needed from feedback.
- Split prototype into small chunks.
- Adjust tests for each small chunks.
- Start to submit prototype chunks into review.openstack.org (disabling whole component until ready to turn on).
Design
High availability
In order to achieve high availability of this new orchestration layer the following key concepts must be build into the design the start.
- A set of atomic tasks that can be organized into a workflow.
- Task resumption and rollback.
- Task tracking.
- Resource locking.
- Workflow sharding.
- Simplicity (allowing for extension and verifiability).