The migration tags provide new means of controlling hbal's behavior. Document the precise semantics in the man page.
Signed-off-by: Klaus Aehlig <[email protected]> --- man/hbal.rst | 25 +++++++++++++++++++++++++ 1 file changed, 25 insertions(+) diff --git a/man/hbal.rst b/man/hbal.rst index 619bd5b..0bf50f6 100644 --- a/man/hbal.rst +++ b/man/hbal.rst @@ -217,6 +217,31 @@ cluster tags *htools:iextags:a*, *htools:iextags:b* Both the above forms mean that two instances both having (e.g.) the tag *a:foo* or *b:bar* won't end on the same node. +MIGRATION TAGS +~~~~~~~~~~~~~~ + +If Ganeti is deployed on a heterogeneous cluster, migration might +not be possible between all nodes of a node group. One example of +such a situation is upgrading the hypervisor node by node. To make +hbal aware of those restrictions, the following cluster tags are used. + +cluster tags *htools:migration:a*, *htools:migration:b*, etc + This make make node tags of the form *a:\**, *b:\**, etc be considered + migration restriction. More precisely, the suffix of cluster tags starting + with *htools:migration:* will become the prefix of the migration tags. + Only those migrations will be taken into consideration where all migration + tags of the source node are also present on the target node. + +cluster tags *htools:allowmigration:x::y* for migration tags *x* and *y* + This asserts that a node taged *y* is able to receive instances in + the same way as if they had an *x* tag. + +So in the simple case of a hypervisor upgrade, tagging all the nodes +that have been upgraded with a migration tag suffices. In more complicated +situations, it is always possible to use a different migration tag for +each hypervisor used and explictly state the allowed migration directions +by means of *htools:allowmigration:* tags. + OPTIONS ------- -- 2.1.0.rc2.206.gedb03e5
