Revision 25ee7fd8 doc/design-multi-reloc.rst
b/doc/design-multi-reloc.rst | ||
---|---|---|
23 | 23 |
to another group for policy reasons, or completely empty a given group |
24 | 24 |
to perform maintenance operations. |
25 | 25 |
|
26 |
To implement this, we propose a new ``multi-relocate`` IAllocator call |
|
27 |
that will be able to compute inter-group instance moves, taking into |
|
28 |
account mobility domains as appropriate. The interface proposed below |
|
29 |
should be enough to cover the use cases mentioned above. |
|
26 |
To implement this, we propose the addition of new IAllocator calls to |
|
27 |
compute inter-group instance moves and group-aware node evacuation, |
|
28 |
taking into account mobility domains as appropriate. The interface |
|
29 |
proposed below should be enough to cover the use cases mentioned above. |
|
30 |
|
|
31 |
With the implementation of this design proposal, the previous |
|
32 |
``multi-evacuate`` mode will be deprecated. |
|
30 | 33 |
|
31 | 34 |
.. _multi-reloc-detailed-design: |
32 | 35 |
|
33 | 36 |
Detailed design |
34 | 37 |
=============== |
35 | 38 |
|
36 |
We introduce a new ``multi-relocate`` IAllocator call whose input will |
|
37 |
be a list of instances to move, and a "mode of operation" that will |
|
38 |
determine what groups will be candidates to receive the new instances. |
|
39 |
|
|
40 |
The mode of operation will be one of: |
|
39 |
All requests honor the groups' ``alloc_policy`` attribute. |
|
41 | 40 |
|
42 |
- *Stay in group*: the instances will be moved off their current nodes, |
|
43 |
but will stay in the same group; this is what the ``relocate`` call |
|
44 |
does, but here it can act on multiple instances. (Typically, the |
|
45 |
source nodes will be marked as drained, to avoid just exchanging |
|
46 |
instances among them.) |
|
41 |
Changing instance's groups |
|
42 |
-------------------------- |
|
47 | 43 |
|
48 |
- *Change group*: this mode accepts one extra parameter, a list of node |
|
49 |
group UUIDs; the instances will be moved away from their current |
|
50 |
group, to any of the groups in this list. If the list is empty, the |
|
51 |
request is, simply, "change group": the instances are placed in any |
|
52 |
group but their original one. |
|
44 |
Takes a list of instances and a list of node group UUIDs; the instances |
|
45 |
will be moved away from their current group, to any of the groups in the |
|
46 |
target list. All instances need to have their primary node in the same |
|
47 |
group, which may not be a target group. If the target group list is |
|
48 |
empty, the request is simply "change group" and the instances are placed |
|
49 |
in any group but their original one. |
|
53 | 50 |
|
54 |
- *Any*: for each instance, any group is valid, including its current
|
|
55 |
one.
|
|
51 |
Node evacuation
|
|
52 |
---------------
|
|
56 | 53 |
|
57 |
In all modes, the groups' ``alloc_policy`` attribute will be honored. |
|
54 |
Evacuates instances off their primary nodes. The evacuation mode |
|
55 |
can be given as ``primary-only``, ``secondary-only`` or |
|
56 |
``all``. The call is given a list of instances whose primary nodes need |
|
57 |
to be in the same node group. The returned nodes need to be in the same |
|
58 |
group as the original primary node. |
|
58 | 59 |
|
59 | 60 |
.. _multi-reloc-result: |
60 | 61 |
|
... | ... | |
66 | 67 |
(when shared storage is used, they will all be failover or migration |
67 | 68 |
operations within the corresponding mobility domain). |
68 | 69 |
|
69 |
The result is expected to be a list of jobsets. Each jobset contains |
|
70 |
lists of serialized opcodes. Example:: |
|
70 |
The result of the operations described above must contain two lists of |
|
71 |
instances and a list of jobsets. |
|
72 |
|
|
73 |
The two lists of instances describe which instances could be |
|
74 |
moved/migrated and which couldn't for some reason ("unsuccessful"). The |
|
75 |
union of the two lists must be equal to the set of instances given in |
|
76 |
the original request. |
|
77 |
|
|
78 |
The list of jobsets contained in the result describe how to actually |
|
79 |
execute the operation. Each jobset contains lists of serialized opcodes. |
|
80 |
Example:: |
|
71 | 81 |
|
72 | 82 |
[ |
73 | 83 |
[ |
... | ... | |
101 | 111 |
Starting with the first set, Ganeti will submit all jobs of a set at the |
102 | 112 |
same time, enabling execution in parallel. Upon completion of all jobs |
103 | 113 |
in a set, the process is repeated for the next one. Ganeti is at liberty |
104 |
to abort the execution of the relocation after any jobset. In such a
|
|
105 |
case the user is notified and can restart the relocation.
|
|
114 |
to abort the execution after any jobset. In such a case the user is
|
|
115 |
notified and can restart the operation.
|
|
106 | 116 |
|
107 | 117 |
.. vim: set textwidth=72 : |
108 | 118 |
.. Local Variables: |
Also available in: Unified diff