Revision 921319f5

b/doc/design-upgrade.rst
154 154

  
155 155

  
156 156

  
157
gnt-upgrade
158
-----------
157
gnt-cluster upgrade
158
-------------------
159 159

  
160
The actual upgrade process will be done by a new binary,
161
``gnt-upgrade``. It will take precisely one argument, the version to
160
The actual upgrade process will be done by a new command ``upgrade`` to
161
``gnt-cluster``. If called with the option ``--to`` which take precisely
162
one argument, the version to
162 163
upgrade (or downgrade) to, given as full string with major, minor, suffix,
163 164
and suffix. To be compatible with current configuration upgrade and downgrade
164 165
procedures, the new version must be of the same major version and
165 166
either an equal or higher minor version, or precisely the previous
166 167
minor version.
167 168

  
168
When executed, ``gnt-upgrade`` will perform the following actions.
169
When executed, ``gnt-cluster upgrade --to=<version>`` will perform the
170
following actions.
169 171

  
170 172
- It verifies that the version to change to is installed on all nodes
171 173
  of the cluster that are not marked as offline. If this is not the
......
174 176

  
175 177
- An intent-to-upgrade file is created that contains the current
176 178
  version of ganeti, the version to change to, and the process ID of
177
  the ``gnt-upgrade`` process. The latter is not used automatically,
179
  the ``gnt-cluster upgrade`` process. The latter is not used automatically,
178 180
  but allows manual detection if the upgrade process died
179 181
  unintentionally. The intend-to-upgrade file is persisted to disk
180 182
  before continuing.
......
199 201

  
200 202
- A backup of all Ganeti-related status information is created for
201 203
  manual rollbacks. While the normal way of rolling back after an
202
  upgrade should be calling ``gnt-upgrade`` from the newer version
204
  upgrade should be calling ``gnt-clsuter upgrade`` from the newer version
203 205
  with the older version as argument, a full backup provides an
204 206
  additional safety net, especially for jump-upgrades (skipping
205 207
  intermediate minor versions).
......
232 234
=======================================================
233 235
 
234 236
During the upgrade procedure, the only ganeti process still running is
235
the one instance of ``gnt-upgrade``. This process is also responsible
237
the one instance of ``gnt-cluster upgrade``. This process is also responsible
236 238
for eventually removing the queue drain. Therefore, we have to provide
237 239
means to resume this process, if it dies unintentionally. The process
238 240
itself will handle SIGTERM gracefully by either undoing all changes
......
242 244
through to the end), or not (in which case the actions done so far are
243 245
rolled back).
244 246

  
245
To achieve this, ``gnt-upgrade`` will support a ``--resume``
246
option. It is recommended to have ``gnt-upgrade --resume`` as an
247
at-reboot task in the crontab. If started with this option,
248
``gnt-upgrade`` does not accept any arguments. It first verifies that
247
To achieve this, ``gnt-cluster upgrade`` will support a ``--resume``
248
option. It is recommended
249
to have ``gnt-cluster upgrade --resume`` as an at-reboot task in the crontab.
250
The ``gnt-cluster upgrade --resume`` comand first verifies that
249 251
it is running on the master node, using the same requirement as for
250 252
starting the master daemon, i.e., confirmed by a majority of all
251 253
nodes. If it is not the master node, it will remove any possibly
......
255 257
resume at the appropriate stage.
256 258

  
257 259
- If the configuration file still is at the initial version,
258
  ``gnt-upgrade`` is resumed at the step immediately following the
260
  ``gnt-cluster upgrade`` is resumed at the step immediately following the
259 261
  writing of the intend-to-upgrade file. It should be noted that
260 262
  all steps before changing the configuration are idempotent, so
261 263
  redoing them does not do any harm.
......
271 273
Caveats
272 274
=======
273 275

  
274
Since ``gnt-upgrade`` drains the queue and undrains it later, so any
276
Since ``gnt-cluster upgrade`` drains the queue and undrains it later, so any
275 277
information about a previous drain gets lost. This problem will
276 278
disappear, once :doc:`design-optables` is implemented, as then the
277 279
undrain will then be restricted to filters by gnt-upgrade.

Also available in: Unified diff