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
Copy file name to clipboardExpand all lines: modules/operator-upgrade.adoc
+15-14Lines changed: 15 additions & 14 deletions
Original file line number
Diff line number
Diff line change
@@ -14,7 +14,7 @@ When the {productname} Operator is installed by Operator Lifecycle Manager, it m
14
14
====
15
15
16
16
[id="upgrading-quay-operator"]
17
-
== Upgrading the Quay Operator
17
+
== Upgrading the {productname} Operator
18
18
19
19
The standard approach for upgrading installed Operators on {ocp} is documented at link:https://docs.openshift.com/container-platform/{ocp-y}/operators/admin/olm-upgrading-operators.html[Upgrading installed Operators].
20
20
@@ -28,26 +28,22 @@ In general, {productname} supports upgrades from a prior (N-1) minor version onl
28
28
29
29
This is required to ensure that any necessary database migrations are done correctly and in the right order during the upgrade.
30
30
31
-
In some cases, {productname} supports direct, single-step upgrades from prior (N-2, N-3) minor versions. This simplifies the upgrade procedure for customers on older releases. The following upgrade paths are supported:
31
+
In some cases, {productname} supports direct, single-step upgrades from prior (N-2, N-3) minor versions. This simplifies the upgrade procedure for customers on older releases. The following upgrade paths are supported for {productname} {producty}:
32
32
33
-
. 3.3.z -> 3.6.z
34
-
. 3.4.z -> 3.6.z
35
-
. 3.4.z -> 3.7.z
36
-
. 3.5.z -> 3.7.z
37
-
. 3.7.z -> 3.8.z
38
-
. 3.6.z -> 3.9.z
39
-
. 3.7.z -> 3.9.z
40
-
. 3.8.z -> 3.9.z
33
+
* 3.7.z -> 3.10.z
34
+
* 3.8.z -> 3.10.z
35
+
* 3.9.z -> 3.10.z
41
36
42
37
For users on standalone deployments of {productname} wanting to upgrade to 3.9, see the link:https://access.redhat.com/documentation/en-us/red_hat_quay/{producty}/html-single/upgrade_red_hat_quay/index#standalone_upgrade[Standalone upgrade] guide.
43
38
44
39
[id="upgrading-red-hat-quay"]
45
-
=== Upgrading Quay
40
+
=== Upgrading {productname}
46
41
47
-
To update {productname} from one minor version to the next, for example, 3.4 -> 3.5, you must change the update channel for the {productname} Operator.
42
+
To update {productname} from one minor version to the next, for example, 3.9 -> 3.10, you must change the update channel for the {productname} Operator.
48
43
49
-
For `z` stream upgrades, for example, 3.4.2 -> 3.4.3, updates are released in the major-minor channel that the user initially selected during install. The procedure to perform a `z` stream upgrade depends on the `approvalStrategy` as outlined above. If the approval strategy is set to `Automatic`, the Quay Operator will upgrade automatically to the newest `z` stream. This results in automatic, rolling Quay updates to newer `z` streams with little to no downtime. Otherwise, the update must be manually approved before installation can begin.
44
+
For `z` stream upgrades, for example, 3.9.1 -> 3.9.2, updates are released in the major-minor channel that the user initially selected during install. The procedure to perform a `z` stream upgrade depends on the `approvalStrategy` as outlined above. If the approval strategy is set to `Automatic`, the {productname} Operator upgrades automatically to the newest `z` stream. This results in automatic, rolling {productname} updates to newer `z` streams with little to no downtime. Otherwise, the update must be manually approved before installation can begin.
50
45
46
+
////
51
47
[id="upgrading-postgresql-databases"]
52
48
=== Updating {productname} from 3.8 -> 3.9
53
49
@@ -115,6 +111,7 @@ spec:
115
111
116
112
. After the `quay-app` pod is marked as *Running*, you can reach your {productname} registry.
==== Upgrading with custom SSL/TLS certificate/key pairs without Subject Alternative Names
@@ -160,6 +158,8 @@ If possible, you should regenerate your SSL/TLS certificates with the correct ho
160
158
161
159
The `GODEBUG=x509ignoreCN=0` flag enables the legacy behavior of treating the CommonName field on X.509 certificates as a hostname when no SANs are present. However, this workaround is not recommended, as it will not persist across a redeployment.
When the {productname} Operator starts, it immediately looks for any `QuayRegistries` it can find in the namespace(s) it is configured to watch. When it finds one, the following logic is used:
Copy file name to clipboardExpand all lines: modules/proc_upgrade_standalone.adoc
+79-36Lines changed: 79 additions & 36 deletions
Original file line number
Diff line number
Diff line change
@@ -12,19 +12,22 @@ In general, {productname} supports upgrades from a prior (N-1) minor version onl
12
12
13
13
This is required to ensure that any necessary database migrations are done correctly and in the right order during the upgrade.
14
14
15
-
In some cases, {productname} supports direct, single-step upgrades from prior (N-2, N-3) minor versions. This exception to the normal, prior minor version-only, upgrade simplifies the upgrade procedure for customers on older releases. The following upgrade paths are supported:
15
+
In some cases, {productname} supports direct, single-step upgrades from prior (N-2, N-3) minor versions. This exception to the normal, prior minor version-only, upgrade simplifies the upgrade procedure for customers on older releases. The following upgrade paths are supported for {productname}{producty}:
16
16
17
-
. 3.3.z -> 3.6.z
18
-
. 3.4.z -> 3.6.z
19
-
. 3.4.z -> 3.7.z
20
-
. 3.5.z -> 3.7.z
21
-
. 3.7.z -> 3.9.z
17
+
* 3.7.z -> 3.10.z
18
+
* 3.8.z -> 3.10.z
19
+
* 3.9.z -> 3.10.z
22
20
23
-
//link
24
21
For users wanting to upgrade the {productname} Operator, see link:https://access.redhat.com/documentation/en-us/red_hat_quay/{producty}/html-single/upgrade_red_hat_quay/index#upgrading_quay_by_upgrading_the_quay_operator[Upgrading the {productname} Operator Overview].
25
22
26
23
This document describes the steps needed to perform each individual upgrade. Determine your current version and then follow the steps in sequential order, starting with your current version and working up to your desired target version.
27
24
25
+
//3.10
26
+
* link:https://access.redhat.com/documentation/en-us/red_hat_quay/{producty}/html-single/upgrade_red_hat_quay/index#upgrade_to_3_10_z_from_3_9_z[Upgrade to 3.10.z from 3.9.z]
27
+
* link:https://access.redhat.com/documentation/en-us/red_hat_quay/{producty}/html-single/upgrade_red_hat_quay/index#upgrade_to_3_10_z_from_3_8_z[Upgrade to 3.10.z from 3.9.z]
28
+
* link:https://access.redhat.com/documentation/en-us/red_hat_quay/{producty}/html-single/upgrade_red_hat_quay/index#upgrade_to_3_10_z_from_3_7_z[Upgrade to 3.10.z from 3.7.z]
29
+
30
+
28
31
* link:https://access.redhat.com/documentation/en-us/red_hat_quay/{producty}/html-single/upgrade_red_hat_quay/index#upgrade_to_3_9_z_from_3_8_z[Upgrade to 3.9.z from 3.8.z]
29
32
* link:https://access.redhat.com/documentation/en-us/red_hat_quay/{producty}/html-single/upgrade_red_hat_quay/index#upgrade_to_3_9_z_from_3_7_z[Upgrade to 3.9.z from 3.7.z]
30
33
* link:https://access.redhat.com/documentation/en-us/red_hat_quay/{producty}/html-single/upgrade_red_hat_quay/index#upgrade_to_3_8_z_from_3_7_z[Upgrade to 3.8.z from 3.7.z]
@@ -53,14 +56,52 @@ The general procedure for a manual upgrade consists of the following steps:
53
56
. Start Clair using the new version of the image.
54
57
. Wait until Clair is ready to accept connections before starting the new version of Quay.
55
58
56
-
57
59
== Accessing images
58
60
59
61
Images for Quay 3.4.0 and later are available from link:https://registry.redhat.io[registry.redhat.io] and
60
62
link:https://registry.access.redhat.com[registry.access.redhat.com], with authentication set up as described in link:https://access.redhat.com/RegistryAuthentication[Red Hat Container Registry Authentication].
61
63
62
64
Images for Quay 3.3.4 and earlier are available from link:https://quay.io[quay.io], with authentication set up as described in link:https://access.redhat.com/solutions/3533201[Accessing {productname} without a CoreOS login].
If you are upgrading your standalone {productname} deployment from 3.8.z -> 3.9, it is highly recommended that you upgrade PostgreSQL from version 10 -> 13. To upgrade PostgreSQL from 10 -> 13, you must bring down your PostgreSQL 10 database and run a migration script to initiate the process.
If you are upgrading your standalone {productname} deployment from 3.8.z -> 3.9, it is highly recommended that you upgrade PostgreSQL from version 10 -> 13. To upgrade PostgreSQL from 10 -> 13, you must bring down your PostgreSQL 10 database and run a migration script to initiate the process:
218
+
If you are upgrading your standalone {productname} deployment from 3.7.z -> 3.9, it is highly recommended that you upgrade PostgreSQL from version 10 -> 13. To upgrade PostgreSQL from 10 -> 13, you must bring down your PostgreSQL 10 database and run a migration script to initiate the process:
176
219
177
220
[NOTE]
178
221
====
179
222
* When upgrading from {productname} 3.7 to 3.9, you might receive the following error: `pg_dumpall: error: query failed: ERROR: xlog flush request 1/B446CCD8 is not satisfied --- flushed only to 1/B0013858`. As a workaround to this issue, you can delete the `quayregistry-clair-postgres-upgrade` job on your {ocp} deployment, which should resolve the issue.
0 commit comments