On Mon, Jun 06, 2011 at 05:11:15PM +0200, Michael Hanselmann wrote:
> A while ago a new ``multi-relocate`` mode was proposed and documented.
> As it turned out, the interface had some deficiencies. With this patch
> The relocation modes are reduced to two and split into separate
> iallocator request modes: node-evacuate and change-group. Some request
> and response requirements are clarified in the documentation.
>
> Signed-off-by: Michael Hanselmann <[email protected]>
> ---
> doc/design-multi-reloc.rst | 57 ++++++++++++++++++++++++-------------------
> doc/iallocator.rst | 42 ++++++++++++++++++--------------
> 2 files changed, 56 insertions(+), 43 deletions(-)
>
> diff --git a/doc/design-multi-reloc.rst b/doc/design-multi-reloc.rst
> index f4b581c..7f0d254 100644
> --- a/doc/design-multi-reloc.rst
> +++ b/doc/design-multi-reloc.rst
> @@ -23,38 +23,36 @@ groups so that, for example, it is possible to move a set
> of instances
> 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.
Maybe we should mention that the old multi-evac is 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.
> +All requests honor the groups' ``alloc_policy`` attribute.
>
> -The mode of operation will be one of:
> +Changing instance's groups
> +--------------------------
>
> -- *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.)
> +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
> +this list. If the list is empty, the request is simply "change group"
> +and the instances are placed in any group but their original one.
Plus mention that for the moment, all instances must come from the same
group?
> -- *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.
> +Node evacuation
> +---------------
>
> -- *Any*: for each instance, any group is valid, including its current
> - one.
> +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.
>
> -In all modes, the groups' ``alloc_policy`` attribute will be honored.
> +The iallocator can decide whether it wants to keep instances in the same
> +node group or move them to another group.
IMHO this shouldn't be doable. The node evac is simply in-group. Any
inter-group moves need to be handled via change-group.
>
> .. _multi-reloc-result:
>
> @@ -66,8 +64,17 @@ of **replace secondary**, **migration** and **failover**
> operations
> (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 jobsets.
> +
> +The two lists of instances describe which instances could be
> +moved/migrated and which couldn't for some reason ("unsuccessful"). The
> +union of the two lists must be equal to the set of instances given in
> +the original request.
> +
> +The list of jobsets contained in the result describe how to actually
> +execute the operation. Each jobset contains lists of serialized opcodes.
> +Example::
>
> [
> [
> @@ -101,8 +108,8 @@ Accepted opcodes:
> 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.
> +to abort the execution after any jobset. In such a case the user is
> +notified and can restart the operation.
>
> .. vim: set textwidth=72 :
> .. Local Variables:
> diff --git a/doc/iallocator.rst b/doc/iallocator.rst
> index 6ecd626..0e4f843 100644
> --- a/doc/iallocator.rst
> +++ b/doc/iallocator.rst
> @@ -1,7 +1,7 @@
> Ganeti automatic instance allocation
> ====================================
>
> -Documents Ganeti version 2.1
> +Documents Ganeti version 2.4
>
> .. contents::
>
> @@ -193,11 +193,14 @@ In all cases, it includes:
> ``multi-relocate`` or ``multi-evacuate``. The ``allocate`` request
> is used when a new instance needs to be placed on the cluster. The
> ``relocate`` request is used when an existing instance needs to be
> - moved within its node group, while the ``multi-relocate`` one is
> - able to relocate multiple instances across multiple node groups. The
> - ``multi-evacuate`` protocol requests that the script computes the
> - optimal relocate solution for all secondary instances of the given
> - nodes.
> + moved within its node group. The ``multi-evacuate`` protocol
> + requests that the script computes the optimal relocate solution for
> + all secondary instances of the given nodes.
… and is marked deprecated.
> + The ``change-group`` request is used to relocate multiple instances
> + across multiple node groups. ``node-evacuate`` evacuates instances
> + off their node(s). These are described in a separate :ref:`design
> + document <multi-reloc-detailed-design>`.
>
> For both allocate and relocate mode, the following extra keys are needed
> in the ``request`` dictionary:
> @@ -276,23 +279,26 @@ Relocation:
> Ganeti 2.0, this list will always contain a single node, the
> current secondary of the instance); type *list of strings*
>
> -As for ``multi-relocate``, it needs the three following request
> -arguments:
> +As for ``node-evacuate``, it needs the following request arguments:
>
> instances
> - a list of instance names to relocate; type *list of strings*
> + a list of instance names to evacuate; type *list of strings*
> +
> + evac_mode
> + specify which instances to evacuate; one of ``primary-only``,
> + ``secondary-only``, ``all``, type *string*
> +
>
> - reloc_mode
> - a string indicating the relocation mode; there are three possible
> - values for this string: *keep_group*, *change_group*, and
> - *any_group*, the semantics or which are explained in :ref:`the
> - design document <multi-reloc-detailed-design>`
> +``change-group`` needs the following request arguments:
> +
> + instances
> + a list of instance names whose group to change; type
> + *list of strings*
>
> target_groups
> - this argument is only accepted when ``reloc_mode``, as explained
> - above, is *change_group*; if present, it must either be the empty
> - list, or contain a list of group UUIDs that should be considered for
> - relocating instances to; type *list of strings*
> + must either be the empty list, or contain a list of group UUIDs that
> + should be considered for relocating instances to; type
> + *list of strings*
>
> Finally, in the case of multi-evacuate, there's one single request
> argument (in addition to ``type``):
thanks,
iustin
