Update docs changes for 3.10 (#841)

Co-authored-by: Steven Smith <[email protected]>

modules/operator-upgrade.adoc

@@ -14,7 +14,7 @@ When the {productname} Operator is installed by Operator Lifecycle Manager, it m
 ====
 
 [id="upgrading-quay-operator"]
-== Upgrading the Quay Operator
+== Upgrading the {productname} Operator
 
 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].
 
@@ -28,26 +28,22 @@ In general, {productname} supports upgrades from a prior (N-1) minor version onl
 
 This is required to ensure that any necessary database migrations are done correctly and in the right order during the upgrade.
 
-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:
+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}:
 
-. 3.3.z -> 3.6.z
-. 3.4.z -> 3.6.z
-. 3.4.z -> 3.7.z
-. 3.5.z -> 3.7.z
-. 3.7.z -> 3.8.z
-. 3.6.z -> 3.9.z
-. 3.7.z -> 3.9.z
-. 3.8.z -> 3.9.z
+* 3.7.z -> 3.10.z
+* 3.8.z -> 3.10.z
+* 3.9.z -> 3.10.z
 
 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.
 
 [id="upgrading-red-hat-quay"]
-=== Upgrading Quay
+=== Upgrading {productname}
 
-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.
+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.
 
-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.
+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.
 
+////
 [id="upgrading-postgresql-databases"]
 === Updating {productname} from 3.8 -> 3.9
 
@@ -115,6 +111,7 @@ spec:
 
 . After the `quay-app` pod is marked as *Running*, you can reach your {productname} registry. 
 
+
 [id="upgrade-33-36"]
 === Upgrading directly from 3.3.z or 3.4.z to 3.6
 
@@ -146,6 +143,7 @@ spec:
     database:
 ...
 ----
+////
 
 [id="upgrading-with-tls-cert-key-pairs-without-san"]
 ==== 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
 
 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.
 
+////
+
 [id="configuring-clair-v4-upgrading-from-33-34-to-36"]
 ==== Configuring Clair v4 when upgrading from 3.3.z or 3.4.z to 3.6 using the {productname} Operator
 
@@ -189,6 +189,7 @@ When upgrading from {productname} 3.3.z to 3.6.z, some users might receive the f
       swift_password: *****
       swift_user: *****
 ----
+////
 
 [id="changin-update-channel-for-operator"]
 === Changing the update channel for the {productname} Operator
@@ -209,7 +210,7 @@ The list of Installed Operators provides a high-level summary of the current Qua
 image:installed-operators-list.png[Installed Operators]
 
 [id="upgrading-quayregistry"]
-== Upgrading a QuayRegistry
+== Upgrading a QuayRegistry resource
 
 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:
 

modules/proc_upgrade_standalone.adoc

@@ -12,19 +12,22 @@ In general, {productname} supports upgrades from a prior (N-1) minor version onl
 
 This is required to ensure that any necessary database migrations are done correctly and in the right order during the upgrade.
 
-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:
+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}:
 
-. 3.3.z -> 3.6.z
-. 3.4.z -> 3.6.z
-. 3.4.z -> 3.7.z
-. 3.5.z -> 3.7.z
-. 3.7.z -> 3.9.z
+* 3.7.z -> 3.10.z
+* 3.8.z -> 3.10.z
+* 3.9.z -> 3.10.z
 
-//link
 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].
 
 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.
 
+//3.10
+* 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]
+* 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]
+* 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]
+
+
 * 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]
 * 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]
 * 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:
 . Start Clair using the new version of the image.
 . Wait until Clair is ready to accept connections before starting the new version of Quay.
 
-
 == Accessing images
 
 Images for Quay 3.4.0 and later are available from link:https://registry.redhat.io[registry.redhat.io] and
 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].
 
 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].
 
+== Upgrade to 3.10.z from 3.9.z
+
+=== Target images
+* **Quay:** {productrepo}/{quayimage}:{productminv}
+ifdef::downstream[]
+* **Clair:** {productrepo}/{clairimage}:{productminv}
+endif::downstream[]
+ifdef::upstream[]
+* **Clair:** {productrepo}/{clairimage}:{clairproductminv}
+endif::upstream[]
+* **PostgreSQL:** {postgresimage}
+* **Redis:** {redisimage}
+
+== Upgrade to 3.10.z from 3.8.z
+
+=== Target images
+* **Quay:** {productrepo}/{quayimage}:{productminv}
+ifdef::downstream[]
+* **Clair:** {productrepo}/{clairimage}:{productminv}
+endif::downstream[]
+ifdef::upstream[]
+* **Clair:** {productrepo}/{clairimage}:{clairproductminv}
+endif::upstream[]
+* **PostgreSQL:** {postgresimage}
+* **Redis:** {redisimage}
+
+== Upgrade to 3.10.z from 3.7.z
+
+=== Target images
+* **Quay:** {productrepo}/{quayimage}:{productminv}
+ifdef::downstream[]
+* **Clair:** {productrepo}/{clairimage}:{productminv}
+endif::downstream[]
+ifdef::upstream[]
+* **Clair:** {productrepo}/{clairimage}:{clairproductminv}
+endif::upstream[]
+* **PostgreSQL:** {postgresimage}
+* **Redis:** {redisimage}
+
 == Upgrade to 3.9.z from 3.8.z
 
 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. 
@@ -159,88 +200,90 @@ registry.redhat.io/quay/clair-rhel8:v3.9.0
 
 For more information, see link:https://github.com/sclorg/postgresql-container/tree/master/13#data-migration[Data Migration].
 
+//updating target images is where you left
+
 === Target images
-* **Quay:** {productrepo}/{quayimage}:{productminv}
+* **Quay:** {productrepo}/{quayimage}:v3.9.0
 ifdef::downstream[]
-* **Clair:** {productrepo}/{clairimage}:{clairproductminv}
+* **Clair:** {productrepo}/{clairimage}:v3.9.0
 endif::downstream[]
 ifdef::upstream[]
 * **Clair:** {productrepo}/{clairimage}:{clairproductminv}
 endif::upstream[]
-* **PostgreSQL:** registry.redhat.io/rhel8/postgresql-13:1-109
-* **Redis:** registry.redhat.io/rhel8/redis-6:1-110)
+* **PostgreSQL:** {postgresimage}
+* **Redis:** {redisimage}
 
 == Upgrade to 3.9.z from 3.7.z
 
-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.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:
 
 [NOTE]
 ====
 * 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.
 ====
 
 === Target images
-* **Quay:** {productrepo}/{quayimage}:{productminv}
+* **Quay:** {productrepo}/{quayimage}:v3.9.0
 ifdef::downstream[]
-* **Clair:** {productrepo}/{clairimage}:{clairproductminv}
+* **Clair:** {productrepo}/{clairimage}:v3.9.0
 endif::downstream[]
 ifdef::upstream[]
 * **Clair:** {productrepo}/{clairimage}:{clairproductminv}
 endif::upstream[]
-* **PostgreSQL:** registry.redhat.io/rhel8/postgresql-13:1-109
-* **Redis:** registry.redhat.io/rhel8/redis-6:1-110)
+* **PostgreSQL:** {postgresimage}
+* **Redis:** {redisimage}
 
 == Upgrade to 3.8.z from 3.7.z
 
 === Target images
 * **Quay:** {productrepo}/{quayimage}:v3.8.0
 ifdef::downstream[]
-* **Clair:** {productrepo}/{clairimage}:{clairproductminv}
+* **Clair:** {productrepo}/{clairimage}:v3.8.0
 endif::downstream[]
 ifdef::upstream[]
 * **Clair:** {productrepo}/{clairimage}:{clairproductminv}
 endif::upstream[]
-* **PostgreSQL:** registry.redhat.io/rhel8/postgresql-13:1-109
-* **Redis:** registry.redhat.io/rhel8/redis-6:1-110)
+* **PostgreSQL:** {postgresimage}
+* **Redis:** {redisimage}
 
 == Upgrade to 3.7.z from 3.6.z
 
 === Target images
 * **Quay:** {productrepo}/{quayimage}:v3.7.0
 ifdef::downstream[]
-* **Clair:** {productrepo}/{clairimage}:{clairproductminv}
+* **Clair:** {productrepo}/{clairimage}:v3.7.0
 endif::downstream[]
 ifdef::upstream[]
 * **Clair:** {productrepo}/{clairimage}:{clairproductminv}
 endif::upstream[]
-* **PostgreSQL:** registry.redhat.io/rhel8/postgresql-13:1-109
-* **Redis:** registry.redhat.io/rhel8/redis-6:1-110)
+* **PostgreSQL:** {postgresimage}
+* **Redis:** {redisimage}
 
 == Upgrade to 3.7.z from 3.5.z
 
 === Target images
 * **Quay:** {productrepo}/{quayimage}:v3.7.0
 ifdef::downstream[]
-* **Clair:** {productrepo}/{clairimage}:{clairproductminv}
+* **Clair:** {productrepo}/{clairimage}:v3.7.0
 endif::downstream[]
 ifdef::upstream[]
 * **Clair:** {productrepo}/{clairimage}:{clairproductminv}
 endif::upstream[]
-* **PostgreSQL:** registry.redhat.io/rhel8/postgresql-13:1-109
-* **Redis:** registry.redhat.io/rhel8/redis-6:1-110)
+* **PostgreSQL:** {postgresimage}
+* **Redis:** {redisimage}
 
 == Upgrade to 3.7.z from 3.4.z
 
 === Target images
 * **Quay:** {productrepo}/{quayimage}:v3.7.0
 ifdef::downstream[]
-* **Clair:** {productrepo}/{clairimage}:{clairproductminv}
+* **Clair:** {productrepo}/{clairimage}:v3.7.0
 endif::downstream[]
 ifdef::upstream[]
 * **Clair:** {productrepo}/{clairimage}:{clairproductminv}
 endif::upstream[]
-* **PostgreSQL:** registry.redhat.io/rhel8/postgresql-13:1-109
-* **Redis:** registry.redhat.io/rhel8/redis-6:1-110)
+* **PostgreSQL:** {postgresimage}
+* **Redis:** {redisimage}
 
 == Upgrade to 3.7.z from 3.3.z
 
@@ -251,13 +294,13 @@ Upgrading to {productname} 3.7 from 3.3. is unsupported. Users must first upgrad
 === Target images
 * **Quay:** {productrepo}/{quayimage}:v3.6.0
 ifdef::downstream[]
-* **Clair:** {productrepo}/{clairimage}:{clairproductminv}
+* **Clair:** {productrepo}/{clairimage}:v3.6.0
 endif::downstream[]
 ifdef::upstream[]
 * **Clair:** {productrepo}/{clairimage}:{clairproductminv}
 endif::upstream[]
-* **PostgreSQL:** registry.redhat.io/rhel8/postgresql-13:1-109
-* **Redis:** registry.redhat.io/rhel8/redis-6:1-110)
+* **PostgreSQL:** {postgresimage}
+* **Redis:** {redisimage}
 
 == Upgrade to 3.6.z from 3.4.z
 
@@ -278,8 +321,8 @@ endif::downstream[]
 ifdef::upstream[]
 * **Clair:** {productrepo}/{clairimage}:{clairproductminv}
 endif::upstream[]
-* **PostgreSQL:** registry.redhat.io/rhel8/postgresql-13:1-109
-* **Redis:** registry.redhat.io/rhel8/redis-6:1-110)
+* **PostgreSQL:** {postgresimage}
+* **Redis:** {redisimage}
 
 == Upgrade to 3.6.z from 3.3.z
 
@@ -300,8 +343,8 @@ endif::downstream[]
 ifdef::upstream[]
 * **Clair:** {productrepo}/{clairimage}:{clairproductminv}
 endif::upstream[]
-* **PostgreSQL:** registry.redhat.io/rhel8/postgresql-13:1-109
-* **Redis:** registry.redhat.io/rhel8/redis-6:1-110)
+* **PostgreSQL:** {postgresimage}
+* **Redis:** {redisimage}
 
 === Swift configuration when upgrading from 3.3.z to 3.6