Convergence - robustness and scale by default
Clouds are noisy - servers fail to come up, or die when the underlying hypervisor crashes or suffers a power failure.
Large stacks exceed the capacity of a single heat-engine process to update / manage efficiently.
Both these issues can be addressed by three interlocking changes:
- move from using in-process-polling to observe resource state, to an observe-and-notify approach
- move from a call-stack implementation to a continual-
- run each individual convergence step via taskflow via a distributed set of workers
Blueprint information
- Status:
- Complete
- Approver:
- None
- Priority:
- High
- Drafter:
- Clint Byrum
- Direction:
- Approved
- Assignee:
- None
- Definition:
- Superseded
- Series goal:
- None
- Implementation:
-
Unknown
- Milestone target:
- None
- Started by
- Completed by
- Angus Salkeld
Related branches
Related bugs
Sprints
Whiteboard
(therve) It doesn't seem that it's a blueprint. Maybe the introduction to 3 other blueprints? It may be better as mail in the list or something.
Gerrit topic: https:/
Addressed by: https:/
Convergence Specification
Gerrit topic: https:/
Addressed by: https:/
Added UUID to stack table and int id as primary
Addressed by: https:/
Database model and apis for convergence
Gerrit topic: https:/
Gerrit topic: https:/
Addressed by: https:/
Add a config option to enable Convergence
Addressed by: https:/
Convergence Database schema changes
Addressed by: https:/
Push instead of pull resource input data
Addressed by: https:/
Convergence base workflow
Addressed by: https:/
Convergence message bus
Addressed by: https:/
Convergence simulator test scenarios
Addressed by: https:/
Convergence special cases
Addressed by: https:/
Add extra columns for resource table
Gerrit topic: https:/
Addressed by: https:/
DNM: TripleO/Heat convergence testing
Work Items
Dependency tree
* Blueprints in grey have been implemented.
