Revision 921319f5 doc/design-upgrade.rst
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