Revision fda24caf
| b/doc/design-multi-reloc.rst | ||
|---|---|---|
| 68 | 68 |
operations within the corresponding mobility domain). |
| 69 | 69 |
|
| 70 | 70 |
The result of the operations described above must contain two lists of |
| 71 |
instances and a list of jobsets. |
|
| 71 |
instances and a list of jobs (each of which is a list of serialized |
|
| 72 |
opcodes) to actually execute the operation. :doc:`Job dependencies |
|
| 73 |
<design-chained-jobs>` can be used to force jobs to run in a certain |
|
| 74 |
order while still making use of parallelism. |
|
| 72 | 75 |
|
| 73 | 76 |
The two lists of instances describe which instances could be |
| 74 | 77 |
moved/migrated and which couldn't for some reason ("unsuccessful"). The
|
| ... | ... | |
| 93 | 96 |
where ``explanation`` is a string describing why the plugin was not able |
| 94 | 97 |
to relocate the instance. |
| 95 | 98 |
|
| 96 |
The list of jobsets contained in the result describe how to actually |
|
| 97 |
execute the operation. Each jobset contains lists of serialized opcodes. |
|
| 98 |
Example:: |
|
| 99 |
The client is given a list of job IDs (see the :doc:`design for |
|
| 100 |
LU-generated jobs <design-lu-generated-jobs>`) which it can watch. |
|
| 101 |
Failures should be reported to the user. |
|
| 102 |
|
|
| 103 |
.. highlight:: python |
|
| 104 |
|
|
| 105 |
Example job list:: |
|
| 99 | 106 |
|
| 100 | 107 |
[ |
| 108 |
# First job |
|
| 101 | 109 |
[ |
| 102 | 110 |
{ "OP_ID": "OP_INSTANCE_MIGRATE",
|
| 103 | 111 |
"instance_name": "inst1.example.com", |
| ... | ... | |
| 106 | 114 |
"instance_name": "inst2.example.com", |
| 107 | 115 |
}, |
| 108 | 116 |
], |
| 117 |
# Second job |
|
| 109 | 118 |
[ |
| 110 | 119 |
{ "OP_ID": "OP_INSTANCE_REPLACE_DISKS",
|
| 120 |
"depends": [ |
|
| 121 |
[-1, ["success"]], |
|
| 122 |
], |
|
| 111 | 123 |
"instance_name": "inst2.example.com", |
| 112 | 124 |
"mode": "replace_new_secondary", |
| 113 |
"remote_node": "node4.example.com" |
|
| 125 |
"remote_node": "node4.example.com",
|
|
| 114 | 126 |
}, |
| 115 | 127 |
], |
| 128 |
# Third job |
|
| 116 | 129 |
[ |
| 117 | 130 |
{ "OP_ID": "OP_INSTANCE_FAILOVER",
|
| 131 |
"depends": [ |
|
| 132 |
[-2, []], |
|
| 133 |
], |
|
| 118 | 134 |
"instance_name": "inst8.example.com", |
| 119 | 135 |
}, |
| 120 |
] |
|
| 136 |
],
|
|
| 121 | 137 |
] |
| 122 | 138 |
|
| 123 | 139 |
Accepted opcodes: |
| ... | ... | |
| 126 | 142 |
- ``OP_INSTANCE_MIGRATE`` |
| 127 | 143 |
- ``OP_INSTANCE_REPLACE_DISKS`` |
| 128 | 144 |
|
| 129 |
Starting with the first set, Ganeti will submit all jobs of a set at the |
|
| 130 |
same time, enabling execution in parallel. Upon completion of all jobs |
|
| 131 |
in a set, the process is repeated for the next one. Ganeti is at liberty |
|
| 132 |
to abort the execution after any jobset. In such a case the user is |
|
| 133 |
notified and can restart the operation. |
|
| 134 |
|
|
| 135 | 145 |
.. vim: set textwidth=72 : |
| 136 | 146 |
.. Local Variables: |
| 137 | 147 |
.. mode: rst |
Also available in: Unified diff