Difference between revisions of "Obsolete:TheBetterPathToLiveMigrationResizing"
(→Rationale) |
(→Current path) |
||
| Line 14: | Line 14: | ||
=== Current path === | === Current path === | ||
| + | |||
| + | [[File:Live-migrate-happy|Thumb]] | ||
==== The problems ==== | ==== The problems ==== | ||
Revision as of 04:06, 30 April 2013
Contents
The Better Path To Live Migration and Resizing
Rationale
The current code path for resizing and live migration is what you could call hairy in that the state-machine that is used to accomplish these 2 types of tasks (which are by there very nature extremely similar) is itself complex and could benefit from rework around a more organized state-machine which would be orchestrated by an external entity, of which said external entity can handle the intricacies of cross-compute communication as well as state-machine transitions and associated failure scenarios. This will make said operation more reliable and centralize the orchestration of said operations to a single entity, which instead of having multiple functions, one or 2 may suffice. Therefore the complexity of code reviews and understanding the complexity of said operations becomes lower and makes them easier to [test, modify, understand].
Definitions
- Live migration
- Moving a instance (and associated) resources from one compute node to another compute node while the instance is still running.
- Resizing
- Moving a powered-off instance (and associated) resources from one compute node to another compute node which can support the instance with re-sized capabilities (more/less VCPU for example).
