to another group for policy reasons, or completely empty a given group
to perform maintenance operations.
-To implement this, we propose a new ``multi-relocate`` IAllocator call
-that will be able to compute inter-group instance moves, taking into
-account mobility domains as appropriate. The interface proposed below
-should be enough to cover the use cases mentioned above.
+To implement this, we propose the addition of new IAllocator calls to
+compute inter-group instance moves and group-aware node evacuation,
+taking into account mobility domains as appropriate. The interface
+proposed below should be enough to cover the use cases mentioned above.
+
+With the implementation of this design proposal, the previous
+``multi-evacuate`` mode will be deprecated.
.. _multi-reloc-detailed-design:
Detailed design
===============
-We introduce a new ``multi-relocate`` IAllocator call whose input will
-be a list of instances to move, and a "mode of operation" that will
-determine what groups will be candidates to receive the new instances.
-
-The mode of operation will be one of:
+All requests honor the groups' ``alloc_policy`` attribute.
-- *Stay in group*: the instances will be moved off their current nodes,
- but will stay in the same group; this is what the ``relocate`` call
- does, but here it can act on multiple instances. (Typically, the
- source nodes will be marked as drained, to avoid just exchanging
- instances among them.)
+Changing instance's groups
+--------------------------
-- *Change group*: this mode accepts one extra parameter, a list of node
- group UUIDs; the instances will be moved away from their current
- group, to any of the groups in this list. If the list is empty, the
- request is, simply, "change group": the instances are placed in any
- group but their original one.
+Takes a list of instances and a list of node group UUIDs; the instances
+will be moved away from their current group, to any of the groups in the
+target list. All instances need to have their primary node in the same
+group, which may not be a target group. If the target group list is
+empty, the request is simply "change group" and the instances are placed
+in any group but their original one.
-- *Any*: for each instance, any group is valid, including its current
- one.
+Node evacuation
+---------------
-In all modes, the groups' ``alloc_policy`` attribute will be honored.
+Evacuates instances off their primary nodes. The evacuation mode
+can be given as ``primary-only``, ``secondary-only`` or
+``all``. The call is given a list of instances whose primary nodes need
+to be in the same node group. The returned nodes need to be in the same
+group as the original primary node.
.. _multi-reloc-result:
(when shared storage is used, they will all be failover or migration
operations within the corresponding mobility domain).
-The result is expected to be a list of jobsets. Each jobset contains
-lists of serialized opcodes. Example::
+The result of the operations described above must contain two lists of
+instances and a list of jobs (each of which is a list of serialized
+opcodes) to actually execute the operation. :doc:`Job dependencies
+<design-chained-jobs>` can be used to force jobs to run in a certain
+order while still making use of parallelism.
+
+The two lists of instances describe which instances could be
+moved/migrated and which couldn't for some reason ("unsuccessful"). The
+union of the instances in the two lists must be equal to the set of
+instances given in the original request. The successful list of
+instances contains elements as follows::
+
+ (instance name, target group name, [chosen node names])
+
+The choice of names is simply for readability reasons (for example,
+Ganeti could log the computed solution in the job information) and for
+being able to check (manually) for consistency that the generated
+opcodes match the intended target groups/nodes. Note that for the
+node-evacuate operation, the group is not changed, but it should still
+be returned as such (as it's easier to have the same return type for
+both operations).
+
+The unsuccessful list of instances contains elements as follows::
+
+ (instance name, explanation)
+
+where ``explanation`` is a string describing why the plugin was not able
+to relocate the instance.
+
+The client is given a list of job IDs (see the :doc:`design for
+LU-generated jobs <design-lu-generated-jobs>`) which it can watch.
+Failures should be reported to the user.
+
+.. highlight:: python
+
+Example job list::
[
+ # First job
[
{ "OP_ID": "OP_INSTANCE_MIGRATE",
"instance_name": "inst1.example.com",
"instance_name": "inst2.example.com",
},
],
+ # Second job
[
{ "OP_ID": "OP_INSTANCE_REPLACE_DISKS",
+ "depends": [
+ [-1, ["success"]],
+ ],
"instance_name": "inst2.example.com",
"mode": "replace_new_secondary",
- "remote_node": "node4.example.com"
+ "remote_node": "node4.example.com",
},
],
+ # Third job
[
{ "OP_ID": "OP_INSTANCE_FAILOVER",
+ "depends": [
+ [-2, []],
+ ],
"instance_name": "inst8.example.com",
},
- ]
+ ],
]
Accepted opcodes:
- ``OP_INSTANCE_MIGRATE``
- ``OP_INSTANCE_REPLACE_DISKS``
-Starting with the first set, Ganeti will submit all jobs of a set at the
-same time, enabling execution in parallel. Upon completion of all jobs
-in a set, the process is repeated for the next one. Ganeti is at liberty
-to abort the execution of the relocation after any jobset. In such a
-case the user is notified and can restart the relocation.
-
.. vim: set textwidth=72 :
.. Local Variables:
.. mode: rst
projects / ganeti-local / blobdiff