-gnt-upgrade
------------
+gnt-cluster upgrade
+-------------------
-The actual upgrade process will be done by a new binary,
-``gnt-upgrade``. It will take precisely one argument, the version to
+The actual upgrade process will be done by a new command ``upgrade`` to
+``gnt-cluster``. If called with the option ``--to`` which take precisely
+one argument, the version to
upgrade (or downgrade) to, given as full string with major, minor, suffix,
and suffix. To be compatible with current configuration upgrade and downgrade
procedures, the new version must be of the same major version and
either an equal or higher minor version, or precisely the previous
minor version.
-When executed, ``gnt-upgrade`` will perform the following actions.
+When executed, ``gnt-cluster upgrade --to=<version>`` will perform the
+following actions.
- It verifies that the version to change to is installed on all nodes
of the cluster that are not marked as offline. If this is not the
- An intent-to-upgrade file is created that contains the current
version of ganeti, the version to change to, and the process ID of
- the ``gnt-upgrade`` process. The latter is not used automatically,
+ the ``gnt-cluster upgrade`` process. The latter is not used automatically,
but allows manual detection if the upgrade process died
unintentionally. The intend-to-upgrade file is persisted to disk
before continuing.
- A backup of all Ganeti-related status information is created for
manual rollbacks. While the normal way of rolling back after an
- upgrade should be calling ``gnt-upgrade`` from the newer version
+ upgrade should be calling ``gnt-clsuter upgrade`` from the newer version
with the older version as argument, a full backup provides an
additional safety net, especially for jump-upgrades (skipping
intermediate minor versions).
=======================================================
During the upgrade procedure, the only ganeti process still running is
-the one instance of ``gnt-upgrade``. This process is also responsible
+the one instance of ``gnt-cluster upgrade``. This process is also responsible
for eventually removing the queue drain. Therefore, we have to provide
means to resume this process, if it dies unintentionally. The process
itself will handle SIGTERM gracefully by either undoing all changes
through to the end), or not (in which case the actions done so far are
rolled back).
-To achieve this, ``gnt-upgrade`` will support a ``--resume``
-option. It is recommended to have ``gnt-upgrade --resume`` as an
-at-reboot task in the crontab. If started with this option,
-``gnt-upgrade`` does not accept any arguments. It first verifies that
+To achieve this, ``gnt-cluster upgrade`` will support a ``--resume``
+option. It is recommended
+to have ``gnt-cluster upgrade --resume`` as an at-reboot task in the crontab.
+The ``gnt-cluster upgrade --resume`` comand first verifies that
it is running on the master node, using the same requirement as for
starting the master daemon, i.e., confirmed by a majority of all
nodes. If it is not the master node, it will remove any possibly
resume at the appropriate stage.
- If the configuration file still is at the initial version,
- ``gnt-upgrade`` is resumed at the step immediately following the
+ ``gnt-cluster upgrade`` is resumed at the step immediately following the
writing of the intend-to-upgrade file. It should be noted that
all steps before changing the configuration are idempotent, so
redoing them does not do any harm.
Caveats
=======
-Since ``gnt-upgrade`` drains the queue and undrains it later, so any
+Since ``gnt-cluster upgrade`` drains the queue and undrains it later, so any
information about a previous drain gets lost. This problem will
disappear, once :doc:`design-optables` is implemented, as then the
undrain will then be restricted to filters by gnt-upgrade.