|
|
| (15 intermediate revisions by one other user not shown) |
| Line 1: |
Line 1: |
| − | == 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 signal entity, instead of having multiple functions, one or 2 may suffice, which makes the complexity of code reviews and understanding the complexity of said operations lower.
| |
| − |
| |
| − | === 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).
| |
| − |
| |
| − | === Current path ===
| |
| − |
| |
| − | ==== The problems ====
| |
| − |
| |
| − | === Better path ===
| |
| − |
| |
| − | ==== The solutions ====
| |
| − |
| |
| − | === Migration from current to better ===
| |
