From 4a02a3fa01eef214394e867e21db0d2c1704f371 Mon Sep 17 00:00:00 2001 From: Steven Smith Date: Mon, 28 Nov 2022 13:38:16 -0500 Subject: [PATCH] Makes changes to upgrading guide in prepartion for 3.8 --- modules/downgrade-quay-deployment.adoc | 7 +++ modules/operator-ipv6-dual-stack.adoc | 2 +- modules/operator-upgrade.adoc | 59 +------------------------- modules/proc_upgrade_standalone.adoc | 19 +++++++-- modules/rn_3_80.adoc | 4 ++ release_notes/master.adoc | 5 +++ upgrade_quay/master.adoc | 2 + 7 files changed, 36 insertions(+), 62 deletions(-) create mode 100644 modules/downgrade-quay-deployment.adoc diff --git a/modules/downgrade-quay-deployment.adoc b/modules/downgrade-quay-deployment.adoc new file mode 100644 index 000000000..073551822 --- /dev/null +++ b/modules/downgrade-quay-deployment.adoc @@ -0,0 +1,7 @@ +:_content-type: CONCEPT + +[id="downgrade-quay-deployment"] += Downgrading {productname} + +{productname} only supports rolling back, or downgrading, to previous z-stream versions, for example, 3.7.2 -> 3.7.1. Rolling back to previous y-stream versions (3.7.0 -> 3.6.0) is not supported. This is because {productname} updates might contain database schema upgrades that are applied when upgrading to a new version of {productname}. Database schema upgrades are not considered backwards compatible. + diff --git a/modules/operator-ipv6-dual-stack.adoc b/modules/operator-ipv6-dual-stack.adoc index 3f11dc6cd..7ed74b127 100644 --- a/modules/operator-ipv6-dual-stack.adoc +++ b/modules/operator-ipv6-dual-stack.adoc @@ -41,7 +41,7 @@ $ curl /health/instance {"data":{"services":{"auth":true,"database":true,"disk_space":true,"registry_gunicorn":true,"service_key":true,"web_gunicorn":true}},"status_code":200} ---- -After enabling IPv6 in your deployment's `config.yaml`, all {productname} features can be used as normal, so long as your environment is configured to use IPv6 and is not hindered by the xref:ipv6-limitations-38[IPv6 and dual-stack limitations]. +After enabling IPv6 in your deployment's `config.yaml`, all {productname} features can be used as normal, so long as your environment is configured to use IPv6 and is not hindered by the xref:operator-ipv6-limitations-38[IPv6 and dual-stack limitations]. [WARNING] ==== diff --git a/modules/operator-upgrade.adoc b/modules/operator-upgrade.adoc index 3d5dfa76e..8138a5f5f 100644 --- a/modules/operator-upgrade.adoc +++ b/modules/operator-upgrade.adoc @@ -12,7 +12,6 @@ The Quay Operator should be installed and upgraded using the link:https://docs.o When the Quay Operator is installed via Operator Lifecycle Manager, it may be configured to support automatic or manual upgrades. This option is shown on the *Operator Hub* page for the Quay Operator during installation. It can also be found in the Quay Operator `Subscription` object via the `approvalStrategy` field. Choosing `Automatic` means that your Quay Operator will automatically be upgraded whenever a new Operator version is released. If this is not desirable, then the `Manual` approval strategy should be selected. ==== - == Upgrading the Quay Operator The standard approach for upgrading installed Operators on OpenShift is documented at link:https://docs.openshift.com/container-platform/4.7/operators/admin/olm-upgrading-operators.html[Upgrading installed Operators]. @@ -33,8 +32,9 @@ In some cases, {productname} supports direct, single-step upgrades from prior (N . 3.4.z -> 3.6.z . 3.4.z -> 3.7.z . 3.5.z -> 3.7.z +. 3.7.z -> 3.8.z -For users on standalone deployments of Quay wanting to upgrade to 3.7, 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. +For users on standalone deployments of Quay wanting to upgrade to 3.8, 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. === Upgrading Quay @@ -125,7 +125,6 @@ The list of Installed Operators provides a high-level summary of the current Qua image:installed-operators-list.png[Installed Operators] - == Upgrading a QuayRegistry When the Quay 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: @@ -134,60 +133,6 @@ When the Quay Operator starts, it immediately looks for any `QuayRegistries` it * If `status.currentVersion` equals the Operator version, reconcile as normal. * If `status.currentVersion` does not equal the Operator version, check if it can be upgraded. If it can, perform upgrade tasks and set the `status.currentVersion` to the Operator's version once complete. If it cannot be upgraded, return an error and leave the `QuayRegistry` and its deployed Kubernetes objects alone. -== Enabling features in Quay 3.7 - -=== Quota management configuration - -Quota management is now supported under the `FEATURE_QUOTA_MANAGEMENT` property and is turned off by default. To enable quota management, set the feature flag in your `config.yaml` to `true`: - -[source,yaml] ----- -FEATURE_QUOTA_MANAGEMENT: true ----- - -=== Using {productname} to proxy a remote organization configuration - -Using {productname} to proxy a remote organization is now supported under the `FEATURE_PROXY_CACHE` property. To enable proxy cache, set the feature flag in your `confg.yaml` to `true`: - -[source,yaml] ----- -FEATURE_PROXY_CACHE: true ----- - -=== {productname} build enhancements - -Builds can be run on virtualized platforms. Backwards compatibility to run previous build configurations are also available. To enable virtual builds, set the feature flag in your `config.yaml` to `true`: - -[source,yaml] ----- -FEATURE_BUILD_SUPPORT: true ----- - -=== Geo-replication using the {productname} Operator - -Deployments of {productname} with geo-replication is now supported by Operator deployments. To enable geo-replication, set the feature flag in your `config.yaml` to `true`: - -[source,yaml] ----- -FEATURE_STORAGE_REPLICATION: true ----- - -== Enabling features in Quay 3.6 - -=== Console monitoring and alerting - -The support for monitoring Quay 3.6 in the OpenShift console requires that the Operator is installed in all namespaces. If you previously installed the Operator in a specific namespace, delete the Operator itself and reinstall it for all namespaces once the upgrade has taken place. - -=== OCI and Helm support - -Support for Helm and some OCI artifacts is now enabled by default in {productname} 3.6. If you want to explicitly enable the feature, for example, if you are upgrading from a version where it is not enabled by default, you need to reconfigure your Quay deployment to enable the use of OCI artifacts using the following properties: - -[source,yaml] ----- -FEATURE_GENERAL_OCI_SUPPORT: true ----- - - == Upgrading a QuayEcosystem Upgrades are supported from previous versions of the Operator which used the `QuayEcosystem` API for a limited set of configurations. To ensure that migrations do not happen unexpectedly, a special label needs to be applied to the `QuayEcosystem` for it to be migrated. A new `QuayRegistry` will be created for the Operator to manage, but the old `QuayEcosystem` will remain until manually deleted to ensure that you can roll back and still access Quay in case anything goes wrong. To migrate an existing `QuayEcosystem` to a new `QuayRegistry`, follow these steps: diff --git a/modules/proc_upgrade_standalone.adoc b/modules/proc_upgrade_standalone.adoc index b3b7f06be..49284f23c 100644 --- a/modules/proc_upgrade_standalone.adoc +++ b/modules/proc_upgrade_standalone.adoc @@ -16,6 +16,7 @@ In some cases, {productname} supports direct, single-step upgrades from prior (N . 3.4.z -> 3.6.z . 3.4.z -> 3.7.z . 3.5.z -> 3.7.z +. 3.7.z -> 3.8.z For users wanting to upgrade via the Quay 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 Quay by upgrading the Quay Operator]. @@ -23,6 +24,7 @@ For users wanting to upgrade via the Quay Operator, see link:https://access.redh 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. +* link:https://access.redhat.com/documentation/en-us/red_hat_quay/{producty}/html-single/upgrade_red_hat_quay/index#upgrade_to_3_7_z_from_3_6_z[Upgrade to 3.8.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_7_z_from_3_6_z[Upgrade to 3.7.z from 3.6.z] * link:https://access.redhat.com/documentation/en-us/red_hat_quay/{producty}/html-single/upgrade_red_hat_quay/index#upgrade_to_3_7_z_from_3_5_z[Upgrade to 3.7.z from 3.5.z] * link:https://access.redhat.com/documentation/en-us/red_hat_quay/{producty}/html-single/upgrade_red_hat_quay/index#upgrade_to_3_7_z_from_3_4_z[Upgrade to 3.7.z from 3.4.z] @@ -39,10 +41,6 @@ ifdef::downstream[] * link:https://access.redhat.com/documentation/en-us/red_hat_quay/{producty}/html-single/upgrade_red_hat_quay/index#upgrade_to_3_0_5_from_2_9_5[Upgrade to 3.0.5 from 2.9.5] endif::downstream[] - - - - See the link:https://access.redhat.com/documentation/en-us/red_hat_quay/3/html-single/red_hat_quay_release_notes/index[{productname} Release Notes] for information on features for individual releases. The general procedure for a manual upgrade consists of the following steps: @@ -60,6 +58,19 @@ link:https://registry.access.redhat.com[registry.access.redhat.com], with authen 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.8.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:** registry.redhat.io/rhel8/postgresql-10:1 +* **Redis:** registry.redhat.io/rhel8/redis-5:1 + == Upgrade to 3.7.z from 3.6.z === Target images diff --git a/modules/rn_3_80.adoc b/modules/rn_3_80.adoc index 8c4f20c35..2a7cdeca6 100644 --- a/modules/rn_3_80.adoc +++ b/modules/rn_3_80.adoc @@ -175,6 +175,10 @@ For more information, see link:https://issues.redhat.com/browse/PROJQUAY-4588[PR * When running {productname} in the old UI, timed-out sessions would require that a superuser input their password again in the pop-up window. With the new UI, superusers are returned to the main page and required to input their username and password credentials. This is a known issue and will be fixed in a future version of the new UI. +* When `FEATURE_RESTRICTED_USERS` is set to `true`, superusers are unable to create new organizations. This is a known issue and will be fixed in a future version of {productname}. + +* If `FEATURE_RESTRICTED_USERS` or `LDAP_RESTRICTED_USER_FILTER` are set with a user, for example, `user1`, and the same user is also a superuser, they will not be able to create new organizations. This is a known issue. The superuser configuration field should take precedence over the restricted user configuration, however this is also an invalid configuration. {productname} administrators should not set the same user as both a restricted user and a superuser. This will be fixed in a future version of {productname} so that the superuser configuration field takes precedence over the restricted user field + [id="ipv6-limitations-38"] ==== IPv6 and dual-stack limitations: diff --git a/release_notes/master.adoc b/release_notes/master.adoc index 642a0a014..0fc9664d9 100644 --- a/release_notes/master.adoc +++ b/release_notes/master.adoc @@ -14,6 +14,11 @@ include::modules/attributes.adoc[] {productname} is regularly released, containing new features, bug fixes, and software updates. To upgrade {productname} for both standalone and {ocp} deployments, see link:https://access.redhat.com/documentation/en-us/red_hat_quay/{producty}/html/upgrade_red_hat_quay/index[Upgrade {productname}]. +[IMPORTANT] +==== +{productname} only supports rolling back, or downgrading, to previous z-stream versions, for example, 3.7.2 -> 3.7.1. Rolling back to previous y-stream versions (3.7.0 -> 3.6.0) is not supported. This is because {productname} updates might contain database schema upgrades that are applied when upgrading to a new version of {productname}. Database schema upgrades are not considered backwards compatible. +==== + ifdef::downstream[] Documentation for {productname} is versioned with each release. The latest {productname} documentation is available from the link:https://access.redhat.com/documentation/en-us/red_hat_quay[{productname} Documentation] page. Currently, version 3 is the latest major version. diff --git a/upgrade_quay/master.adoc b/upgrade_quay/master.adoc index 3fe885951..13313e021 100644 --- a/upgrade_quay/master.adoc +++ b/upgrade_quay/master.adoc @@ -18,3 +18,5 @@ include::modules/operator-upgrade.adoc[leveloffset=+1] include::modules/proc_upgrade_standalone.adoc[leveloffset=+1] include::modules/qbo-operator-upgrade.adoc[leveloffset=+1] + +include::modules/downgrade-quay-deployment.adoc[leveloffset=+1]