Synnefo » snf-ganeti » ganeti-local

New options

-----------

- HRoller should be able to operate on single nodegroups (-G flag) or

  select its target node through some other mean (eg. via a tag, or a

  regexp). (Note that individual node selection is already possible via

  the -O flag, that makes hroller ignore a node altogether).

- HRoller should handle non redundant instances: currently these are

  ignored but there should be a way to select its behavior between "it's

  ok to reboot a node when a non-redundant instance is on it" or "skip

  nodes with non-redundant instances". This will only be selectable

  globally, and not per instance.

- Hroller will make sure to keep any instance which is up in its current

  state, via live migrations, unless explicitly overridden. The

  algorithm that will be used calculate the rolling reboot with live

  migrations is described below, and any override on considering the

  instance status will only be possible on the whole run, and not

  per-instance.

considered for avoiding contemporary reboot of its primary and secondary

nodes, but will *not* be considered as a target for the node evacuation.

This allows avoiding needlessly moving its primary around, since it

won't suffer a downtime anyway.

Note that a node with non-redundant instances will only ever be

considered good for rolling-reboot if these are down (or the checking of

status is overridden) *and* an explicit option to allow it is set.

   secondary for any instance. This can be done already by the current

   hroller graph coloring algorithm: nodes are in the same set (color)

   if and only if no edge (instance) exists between them (see the

   :manpage:`hroller(1)` manpage for more details).

   node in common (this can be done by creating a graph of nodes that

   are connected if and only if an instance on both has the same

   secondary node, and coloring that graph)

   created at step 2, and then reboot/perform maintenance on them, and

   migrate back their original primaries, which allows the computation

   above to be reused for each following subset without N+1 failures

   being triggered, if none were present before. See below about the

   actual execution of the maintenance.

Hroller should become able to execute rolling maintenances, rather than

just calculate them. For this to succeed properly one of the following

must happen:

- HRoller handles rolling maintenances that happen at the same time as

  unrelated cluster jobs, and thus recalculates the maintenance at each

  step

- HRoller can selectively drain the cluster so it's sure that only the

  rolling maintenance can be going on

Non-redundant (plain or file) instances should have a way to be moved

off as well via plain storage live migration or ``gnt-instance move``

(which requires downtime).