You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Updates for OCP 3.4 cluster upgrade process (automated+manual in-place)
Also logging + cluster upgrade tweaks per QE feedback
Add etcd v2 API note to release notes
Add manual etcd upgrade steps (RPM+containerized)
Add upgrade steps for excluder pkgs
Before upgrading your cluster to {product-title} 3.3, the cluster must be
113
+
Before upgrading your cluster to {product-title} 3.4, the cluster must be
114
114
already upgraded to the
115
-
link:https://docs.openshift.com/enterprise/3.2/release_notes/ose_3_2_release_notes.html#ose-32-asynchronous-errata-updates[latest asynchronous release of version 3.2]. Cluster upgrades cannot span more than one
116
-
minor version at a time, so if your cluster is at version 3.0 or 3.1, you must
117
-
first upgrade incrementally (e.g., 3.0 to 3.1, then 3.1 or 3.2).
115
+
link:https://docs.openshift.com/container-platform/3.3/release_notes/ocp_3_3_release_notes.html#ocp-33-asynchronous-errata-updates[latest asynchronous release of version 3.3]. Cluster upgrades cannot span more than one
116
+
minor version at a time, so if your cluster is at a version earlier than 3.3,
117
+
you must first upgrade incrementally (e.g., 3.1 to 3.2, then 3.2 to 3.3).
118
118
====
119
119
120
120
To prepare for an automated upgrade:
121
121
122
-
. If you are upgrading from version 3.2 to 3.3, manually disable the 3.2 channel and enable the 3.3 channel on each master and node host:
122
+
. If you are upgrading from {product-title} 3.3 to 3.4, manually disable the 3.3
123
+
channel and enable the 3.4 channel on each master and node host:
These packages add entries to the `exclude` directive in the host's
150
+
*_/etc/yum.conf_* file.
151
+
152
+
. You must be logged in as a cluster administrative user on the master host for
153
+
the upgrade to succeed:
139
154
+
140
155
----
141
156
$ oc login
@@ -159,8 +174,8 @@ you should have an installation configuration file located at
159
174
start an upgrade.
160
175
161
176
The installer supports upgrading between minor versions of {product-title}
162
-
(one minor version at a time, e.g., 3.2 to 3.3) as well as between
163
-
xref:../../release_notes/ocp_3_3_release_notes.adoc#ocp-33-asynchronous-errata-updates[asynchronous errata updates] within a minor version (e.g., 3.3.z).
177
+
(one minor version at a time, e.g., 3.3 to 3.4) as well as between
178
+
xref:../../release_notes/ocp_3_3_release_notes.adoc#ocp-33-asynchronous-errata-updates[asynchronous errata updates] within a minor version (e.g., 3.4.z).
164
179
165
180
If you have an older format installation configuration file in
166
181
*_~/.config/openshift/installer.cfg.yml_* from an installation of a previous
. Satisfy the steps in xref:preparing-for-an-automated-upgrade[Preparing for an Automated Upgrade] to ensure you are using the latest upgrade playbooks.
190
+
191
+
. Run the following command on each host to remove the *atomic-openshift* packages
192
+
from the list of yum excludes on the host:
193
+
+
194
+
----
195
+
# atomic-openshift-excluder unexclude
196
+
----
197
+
175
198
. Run the installer with the `upgrade` subcommand:
176
199
+
177
200
----
178
201
# atomic-openshift-installer upgrade
179
202
----
180
203
. Then, follow the on-screen instructions to upgrade to the latest release.
181
204
// tag::automated_upgrade_after_reboot[]
182
-
. When the upgrade finishes, a recommendation will be printed to reboot all hosts.
183
-
After rebooting, if there are no additional features enabled, you can
184
-
xref:verifying-the-upgrade[verify the upgrade]. Otherwise, the next step depends
185
-
on what features are enabled.
205
+
. Run the following command on each host to add the *atomic-openshift* packages
206
+
back to the list of yum excludes on the host:
207
+
+
208
+
----
209
+
# atomic-openshift-excluder exclude
210
+
----
211
+
212
+
. After all master and node upgrades have completed, a recommendation will be
213
+
printed to reboot all hosts. After rebooting, if there are no additional
214
+
features enabled, you can xref:verifying-the-upgrade[verify the upgrade].
215
+
Otherwise, the next step depends on what additional features have you previously
216
+
enabled.
186
217
+
187
218
[cols="1,4"]
188
219
|===
@@ -197,66 +228,178 @@ on what features are enabled.
197
228
// end::automated_upgrade_after_reboot[]
198
229
199
230
[[running-the-upgrade-playbook-directly]]
200
-
== Running the Upgrade Playbook Directly
231
+
== Running Upgrade Playbooks Directly
232
+
233
+
You can run automated upgrade playbooks using Ansible directly, similar to the
234
+
advanced installation method, if you have an inventory file. Playbooks can be
235
+
run using the `ansible-playbook` command.
236
+
237
+
The same *_v3_4_* upgrade playbooks can be used for either of the following
238
+
scenarios:
201
239
202
-
You can run the automated upgrade playbook using Ansible directly, similar
203
-
to the advanced installation method, if you have an inventory file.
240
+
- Upgrading existing {product-title} 3.3 clusters to 3.4
241
+
- Upgrading existing {product-title} 3.4 clusters to the latest
An {product-title} cluster can be upgraded in one or more phases. You can choose
249
+
whether to upgrade all hosts in one phase by running a single Ansible playbook,
250
+
or upgrade the _control plane_ (master components) and nodes in multiple phases
251
+
using separate playbooks.
210
252
211
-
[[upgrading-to-ocp-3-3]]
212
-
=== Upgrading to {product-title} 3.3
253
+
[NOTE]
254
+
====
255
+
Instructions on the full upgrade process and when to call these playbooks are
256
+
described in xref:upgrading-to-ocp-3-4[Upgrading to the Latest {product-title}
257
+
3.4 Release].
258
+
====
259
+
260
+
When upgrading in separate phases, the control plane phase includes upgrading:
261
+
262
+
- etcd
263
+
- master components
264
+
- Docker on any stand-alone etcd hosts
265
+
266
+
It does does not include:
267
+
268
+
- node services running on masters
269
+
- Docker running on masters
270
+
- node services running on stand-alone nodes
271
+
272
+
When upgrading only the nodes, the control plane must already be upgraded. The
273
+
node phase includes upgrading:
274
+
275
+
- node services running on masters and stand-alone nodes
276
+
- Docker running on masters and nodes
213
277
214
-
To run an upgrade from {product-title} 3.2 to 3.3:
278
+
[[customizing-node-upgrades]]
279
+
=== Customizing Node Upgrades
280
+
281
+
Whether upgrading in a single or multiple phases, you can customize how the node
282
+
portion of the upgrade progresses by passing certain Ansible variables to an
283
+
upgrade playbook using the `-e` option.
284
+
285
+
[NOTE]
286
+
====
287
+
Instructions on the full upgrade process and when to call these playbooks are
288
+
described in xref:upgrading-to-ocp-3-4[Upgrading to the Latest {product-title}
289
+
3.4 Release].
290
+
====
291
+
292
+
The `openshift_upgrade_nodes_serial` variable can be set to an integer or
293
+
percentage to control how many node hosts are upgraded at the same time. The
294
+
default is `1`, upgrading nodes one at a time.
295
+
296
+
For example, to upgrade 20 percent of the total number of detected nodes at a
297
+
time:
298
+
299
+
----
300
+
$ ansible-playbook -i <path/to/inventory/file> \
301
+
</path/to/upgrade/playbook> \
302
+
-e openshift_upgrade_nodes_serial="20%"
303
+
----
304
+
305
+
The `openshift_upgrade_nodes_label` variable allows you to specify that only
306
+
nodes with a certain label are upgraded. This can also be combined with the
307
+
`openshift_upgrade_nodes_serial` variable.
308
+
309
+
For example, to only upgrade nodes in the *group1* region, two at a time:
310
+
311
+
----
312
+
$ ansible-playbook -i <path/to/inventory/file> \
313
+
</path/to/upgrade/playbook> \
314
+
-e openshift_upgrade_nodes_serial="2" \
315
+
-e openshift_upgrade_nodes_label="region=group1"
316
+
----
317
+
318
+
See xref:../../admin_guide/manage_nodes.adoc#updating-labels-on-nodes[Manging
319
+
Nodes] for more on node labels.
320
+
321
+
[[upgrading-to-ocp-3-4]]
322
+
=== Upgrading to the Latest {product-title} 3.4 Release
323
+
324
+
To upgrade an existing {product-title} 3.3 or 3.4 cluster to the latest 3.4
325
+
release:
215
326
216
327
. Satisfy the steps in xref:preparing-for-an-automated-upgrade[Preparing for an Automated Upgrade] to ensure you are using the latest upgrade playbooks.
217
-
. Ensure the `*deployment_type*` parameter in your inventory file is set to
328
+
329
+
. Run the following command on each host to remove the *atomic-openshift* packages
330
+
from the list of yum excludes on the host:
331
+
+
332
+
----
333
+
# atomic-openshift-excluder unexclude
334
+
----
335
+
336
+
. Ensure the `deployment_type` parameter in your inventory file is set to
218
337
`openshift-enterprise`.
338
+
219
339
. If you have multiple masters configured and want to enable rolling, full system
220
-
restarts of the hosts, you can set the `*openshift_rolling_restart_mode*`
340
+
restarts of the hosts, you can set the `openshift_rolling_restart_mode`
221
341
parameter in your inventory file to `system`. Otherwise, the default value
222
342
*services* performs rolling service restarts on HA masters, but does not reboot
=== Upgrading to {product-title} 3.3 Asynchronous Releases
241
-
242
-
To apply
243
-
xref:../../release_notes/ocp_3_3_release_notes.html#ocp-33-asynchronous-errata-updates[asynchronous errata updates] to an existing {product-title} 3.3 cluster:
376
+
<1> See xref:customizing-node-upgrades[Customizing Node Upgrades] for any desired
377
+
`<customized_node_upgrade_variables>`.
378
+
+
379
+
*Option B) Upgrade the control plane and nodes in separate phases.*
244
380
381
+
.. To upgrade only the control plane, run the *_upgrade_control_plane.yaml_*
. Satisfy the steps in xref:preparing-for-an-automated-upgrade[Preparing for an Automated Upgrade] to ensure you are using the latest upgrade playbooks.
247
-
. Run the *_v3_3_* upgrade playbook (the same playbook that is used for
248
-
xref:upgrading-to-ocp-3-3[upgrading from {product-title} 3.2 to 3.3]). If your
249
-
inventory file is located somewhere other than the default
250
-
*_/etc/ansible/hosts_*, add the `-i` flag to specify the location. If you
251
-
previously used the `atomic-openshift-installer` command to run your
252
-
installation, you can check *_~/.config/openshift/hosts_* (previously located at
253
-
*_~/.config/openshift/.ansible/hosts_*) for the last inventory file that was
254
-
used, if needed.
389
+
.. To upgrade only the nodes, run the *_upgrade_nodes.yaml_* playbook:
0 commit comments