From b06097bfbc7657167fae7a2a3242602534571aa6 Mon Sep 17 00:00:00 2001 From: Steven Smith Date: Fri, 31 Mar 2023 16:23:35 -0400 Subject: [PATCH] 1 --- deploy_red_hat_quay_operator/master.adoc | 3 + modules/config-preconfigure-automation.adoc | 2 +- modules/config-updates-39.adoc | 47 +++++- ...pping-repositories-to-cpe-information.adoc | 2 +- modules/operator-components-managed.adoc | 9 +- modules/operator-components-unmanaged.adoc | 5 +- modules/operator-managed-postgres.adoc | 7 +- modules/operator-upgrade.adoc | 66 +++++++- modules/rn_3_90.adoc | 28 +++- modules/upgrading-postgresql.adoc | 150 ++++++++++++++++++ 10 files changed, 305 insertions(+), 14 deletions(-) create mode 100644 modules/upgrading-postgresql.adoc diff --git a/deploy_red_hat_quay_operator/master.adoc b/deploy_red_hat_quay_operator/master.adoc index f3511157e..5e8a34a38 100644 --- a/deploy_red_hat_quay_operator/master.adoc +++ b/deploy_red_hat_quay_operator/master.adoc @@ -70,6 +70,9 @@ include::modules/operator-first-user-ui.adoc[leveloffset=+3] //quayregistry status include::modules/operator-quayregistry-status.adoc[leveloffset=+1] +//upgrading 38-39 +include::modules/upgrading-postgresql.adoc[leveloffset=+1] + [role="quay-next-steps"] .Next steps diff --git a/modules/config-preconfigure-automation.adoc b/modules/config-preconfigure-automation.adoc index 2725db708..0ecd94ea6 100644 --- a/modules/config-preconfigure-automation.adoc +++ b/modules/config-preconfigure-automation.adoc @@ -34,7 +34,7 @@ SUPER_USERS: [id="restricting-user-creation"] == Restricting user creation -After users have configured a superuser, they can restrict the ability to create new users to the superuser group by setting FEATURE_USER_CREATION to false. For example: +After you have configured a superuser, you can restrict the ability to create new users to the superuser group by setting the `FEATURE_USER_CREATION` to `false`. For example: [source,yaml] ---- diff --git a/modules/config-updates-39.adoc b/modules/config-updates-39.adoc index bf6aa05b3..8c3fcd780 100644 --- a/modules/config-updates-39.adoc +++ b/modules/config-updates-39.adoc @@ -63,7 +63,7 @@ LOGS_MODEL_CONFIG: The following configuration fields have been added to enhance the {productname} quota management feature. -.{productname} 3.9 configuration fields +.{productname} 3.9 quota management configuration fields [cols="2a,1a,2a",options="header"] |=== |Field | Type |Description @@ -87,7 +87,7 @@ The following configuration fields have been added to enhance the {productname} |=== [id="quota-management-config-settings-39"] -== Possible quota management configuration settings +=== Possible quota management configuration settings The following table explains possible quota management configuration settings in {productname} 3.9. @@ -102,7 +102,7 @@ The following table explains possible quota management configuration settings in |=== [id="suggested-management-config-settings-39-quota"] -== Suggested quota management configuration settings +=== Suggested quota management configuration settings The following YAML is the suggested configuration when enabling quota management. @@ -114,4 +114,43 @@ FEATURE_GARBAGE_COLLECTION: true PERMANENTLY_DELETE_TAGS: true QUOTA_TOTAL_DELAY_SECONDS: 1800 RESET_CHILD_MANIFEST_EXPIRATION: true ----- \ No newline at end of file +---- + +[id=postgresql-pvc-backup-config-fields] +== PostgreSQL PVC backup environment variable + +The following environment variable has been added to configure whether {productname} automatically removes old persistent volume claims (PVCs) when upgrading from version 3.8 -> 3.9: + +.{productname} 3.9 PostgreSQL backup environment variable +[cols="2a,1a,2a",options="header"] +|=== +|Field | Type |Description +| *POSTGRES_UPGRADE_RETAIN_BACKUP* |Boolean | When set to `True`, persistent volume claims from PostgreSQL 10 are backed up. ++ +**Default**: `False` + +|=== + +[id="pvc-backup-example-yaml"] +=== Example configuration for PostgreSQL PVC backup + +The following `Subscription` object provides an example configuration for backing up PostgreSQL 10 PVCs. + +.`Subscription` object for PostgreSQL 10 PVCs +[source,yaml] +---- +apiVersion: operators.coreos.com/v1alpha1 +kind: Subscription +metadata: + name: quay-operator + namespace: quay-enterprise +spec: + channel: stable-3.8 + name: quay-operator + source: redhat-operators + sourceNamespace: openshift-marketplace + config: + env: + - name: POSTGRES_UPGRADE_RETAIN_BACKUP + value: "true" +---- diff --git a/modules/mapping-repositories-to-cpe-information.adoc b/modules/mapping-repositories-to-cpe-information.adoc index 86695ec8d..298df4c43 100644 --- a/modules/mapping-repositories-to-cpe-information.adoc +++ b/modules/mapping-repositories-to-cpe-information.adoc @@ -22,7 +22,7 @@ In addition to uploading CVE information to the database for disconnected Clair * For standalone {productname} and Clair deployments, the mapping file must be loaded into the Clair pod. -* For {productname} Operator deployments on {ocp} and Clair deployments, you must set the Clair component to `unamanged`. Then, Clair must be deployed manually, setting the configuration to load a local copy of the mapping file. +* For {productname} Operator deployments on {ocp} and Clair deployments, you must set the Clair component to `unmanaged`. Then, Clair must be deployed manually, setting the configuration to load a local copy of the mapping file. [id="mapping-repositories-to-cpe-configuration"] == Mapping repositories to Common Product Enumeration example configuration diff --git a/modules/operator-components-managed.adoc b/modules/operator-components-managed.adoc index 4a12a962a..7335f2acb 100644 --- a/modules/operator-components-managed.adoc +++ b/modules/operator-components-managed.adoc @@ -7,10 +7,15 @@ Unless your `QuayRegistry` custom resource specifies otherwise, the {productname * **quay:** Holds overrides for the {productname} deployment. For example, environment variables and number of replicas. This component is new as of {productname} 3.7 and cannot be set to unmanaged. * **postgres:** For storing the registry metadata, ifeval::["{productname}" == "Red Hat Quay"] -uses a version of Postgres 10 from the link:https://www.softwarecollections.org/en/[Software Collections] +As of {productname} 3.9, uses a version of PostgreSQL 13 from link:https://www.softwarecollections.org/en/[Software Collections]. ++ +[NOTE] +==== +When upgrading from {productname} 3.8 -> 3.9, the Operator automatically handles upgrading PostgreSQL 10 to PostgreSQL 13. This upgrade is required. PostgreSQL 10 had its final release on November 10, 2022 and is no longer supported. +==== endif::[] ifeval::["{productname}" == "Project Quay"] -uses an upstream (CentOS) version of Postgres 10 +As of {productname} 3.9, uses an upstream (CentOS) version of PostgreSQL 13. endif::[] * **clair:** Provides image vulnerability scanning. * **redis:** Stores live builder logs and the {productname} tutorial. Also includes the locking mechanism that is required for garbage collection. diff --git a/modules/operator-components-unmanaged.adoc b/modules/operator-components-unmanaged.adoc index 17f33ceef..e5785de8d 100644 --- a/modules/operator-components-unmanaged.adoc +++ b/modules/operator-components-unmanaged.adoc @@ -6,7 +6,9 @@ If you have existing components such as PostgreSQL, Redis, or object storage tha [NOTE] ==== -The {productname} config editor can also be used to create or modify an existing config bundle and simplifies the process of updating the Kubernetes `Secret`, especially for multiple changes. When {productname}'s configuration is changed by the config editor and sent to the {productname} Operator, the deployment is updated to reflect the new configuration. +* The {productname} config editor can also be used to create or modify an existing config bundle and simplifies the process of updating the Kubernetes `Secret`, especially for multiple changes. When {productname}'s configuration is changed by the config editor and sent to the {productname} Operator, the deployment is updated to reflect the new configuration. +* If you are using an unmanaged PostgreSQL database, and the version is PostgreSQL 10, it is highly recommended that you upgrade to PostgreSQL 13. PostgreSQL 10 had its final release on November 10, 2022 and is no longer supported. For more information, see the link:https://www.postgresql.org/support/versioning/[PostgreSQL Versioning Policy]. + ==== See the following sections for configuring unmanaged components: @@ -19,3 +21,4 @@ See the following sections for configuring unmanaged components: * xref:operator-unmanaged-route[Disabling the route component] * xref:operator-unmanaged-monitoring[Disabling the monitoring component] * xref:operator-unmanaged-mirroring[Disabling the mirroring component] + diff --git a/modules/operator-managed-postgres.adoc b/modules/operator-managed-postgres.adoc index a3cc1597c..359323298 100644 --- a/modules/operator-managed-postgres.adoc +++ b/modules/operator-managed-postgres.adoc @@ -2,7 +2,7 @@ [id="operator-managed-postgres"] = Using the managed PostgreSQL database -With {productname} 3.9, if your database is managed by the {productnmame} Operator, updating from {productname} 3.8 -> 3.9 automatically handles upgrading PostgreSQL 10 to PostgreSQL 13. This automatic procedure works by first upgrading your PostgreSQL 10 to PostgreSQL 12, and then from PostgreSQL 12 to PostgreSQL 13. +With {productname} 3.9, if your database is managed by the {productnmame} Operator, updating from {productname} 3.8 -> 3.9 automatically handles upgrading PostgreSQL 10 to PostgreSQL 13. + [IMPORTANT] ==== @@ -13,11 +13,14 @@ If you do not want the {productname} Operator to upgrade your PostgreSQL deploym + [IMPORTANT] ==== -* It is highly recommended to upgrade your PostgreSQL database to version 13. PostgreSQL 10 will reach end of life in May, 2024. +* It is highly recommended that you upgrade to PostgreSQL 13. PostgreSQL 10 had its final release on November 10, 2022 and is no longer supported. For more information, see the link:https://www.postgresql.org/support/versioning/[PostgreSQL Versioning Policy]. + ==== + If you want your PostgreSQL database to match the same version as your {rhel} system, see link:https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html/deploying_different_types_of_servers/using-databases#migrating-to-a-rhel-8-version-of-postgresql_using-postgresql[Migrating to a RHEL 8 version of PostgreSQL] for {rhel-short} 8 or link:https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/9/html/configuring_and_using_database_servers/using-postgresql_configuring-and-using-database-servers#migrating-to-a-rhel-9-version-of-postgresql_using-postgresql[Migrating to a RHEL 9 version of PostgreSQL] for {rhel-short} 9. +For more information about the {productname} 3.8 -> 3.9 procedure, see "Updating {productname} and the {productname} and Clair PostgreSQL databases on {ocp}". + [id="operator-managed-postgres-recommendations"] == PostgreSQL database recommendations diff --git a/modules/operator-upgrade.adoc b/modules/operator-upgrade.adoc index c537af25a..fc9b7183e 100644 --- a/modules/operator-upgrade.adoc +++ b/modules/operator-upgrade.adoc @@ -28,13 +28,15 @@ 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 simplifies the upgrade procedure for customers on older releases. The following upgrade paths are supported: . 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 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. @@ -46,6 +48,68 @@ To update {productname} from one minor version to the next, for example, 3.4 -> 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. +[id="upgrading-postgresql-databases"] +=== Updating {productname} from 3.8 -> 3.9 + +When updating {productname} 3.8 -> 3.9, the Operator automatically upgrades the existing PostgreSQL databases for Clair and {productname} from version 10 to version 13. + +[IMPORTANT] +==== +* This upgrade is irreversible. It is highly recommended that you upgrade to PostgreSQL 13. PostgreSQL 10 had its final release on November 10, 2022 and is no longer supported. For more information, see the link:https://www.postgresql.org/support/versioning/[PostgreSQL Versioning Policy]. +* By default, {productname} is configured to remove old persistent volume claims (PVCs) from PostgreSQL 10. To disable this setting and backup old PVCs, you must set `POSTGRES_UPGRADE_RETAIN_BACKUP` to `True` in your `config.yaml` file. +==== + +.Prerequisites + +* You have installed {productname} 3.8 on {ocp}. +* 100 GB of free, additional storage. ++ +During the upgrade process, additional persistent volume claims (PVCs) are provisioned to store the migrated data. This helps prevent a destructive operation on user data. The upgrade process rolls out PVCs for 50 GB for both the {productname} database upgrade, and the Clair database upgrade. + +.Procedure + +. Optional. Back up your old PVCs from PostgreSQL 10 by setting `POSTGRES_UPGRADE_RETAIN_BACKUP` to `True` your `quay-operator` `Subscription` object. For example: ++ +[source,yaml] +---- +apiVersion: operators.coreos.com/v1alpha1 +kind: Subscription +metadata: + name: quay-operator + namespace: quay-enterprise +spec: + channel: stable-3.8 + name: quay-operator + source: redhat-operators + sourceNamespace: openshift-marketplace + config: + env: + - name: POSTGRES_UPGRADE_RETAIN_BACKUP + value: "true" +---- + +. In the {ocp} Web Console, navigate to *Operators* -> *Installed Operators*. + +. Click on the {productname} Operator. + +. Navigate to the *Subscription* tab. + +. Under *Subscription details* click *Update channel*. + +. Select *stable-3.9* and save the changes. + +. Check the progress of the new installation under *Upgrade status*. Wait until the upgrade status changes to *1 installed* before proceeding. + +. In your {ocp} cluster, navigate to *Workloads* -> *Pods*. Existing pods should be terminated, or in the process of being terminated. + +. Wait for the following pods, which are responsible for upgrading the database and alembic migration of existing data, to spin up: `clair-postgres-upgrade`, `quay-postgres-upgrade`, and `quay-app-upgrade`. + +. After the `clair-postgres-upgrade`, `quay-postgres-upgrade`, and `quay-app-upgrade` pods are marked as *Completed*, the remaining pods for your {productname} deployment spin up. This takes approximately ten minutes. + +. Verify that the `quay-database` and `clair-postgres` pods now use the `postgresql-13` image. + +. 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 diff --git a/modules/rn_3_90.adoc b/modules/rn_3_90.adoc index 210324a11..b082cd9f5 100644 --- a/modules/rn_3_90.adoc +++ b/modules/rn_3_90.adoc @@ -92,16 +92,40 @@ For more information, see link:https://access.redhat.com/documentation/en-us/red ** **FEATURE_SECURITY_SCANNER_NOTIFY_ON_NEW_INDEX**: Whether to allow sending notifications about vulnerabilities for new pushes. + -*Default**: `True` +**Default**: `True` + For more information, see link:https://access.redhat.com/documentation/en-us/red_hat_quay/3/html-single/configure_red_hat_quay/index#config-fields-scanner[Security scanner configuration fields]. +* The following configuration field has been added to configure whether {productname} automatically removes old persistent volume claims (PVCs) when upgrading from version 3.8 -> 3.9: + +** **POSTGRES_UPGRADE_RETAIN_BACKUP**: When set to `True`, persistent volume claims from PostgreSQL 10 are backed up. ++ +**Default**: `False` + [id="quay-operator-updates"] == {productname} Operator The following updates have been made to the {productname} Operator: -* +* Currently, the {productname} Operator and Clair use PostgreSQL 10. PostgreSQL 10 had its final release on November 10, 2022 and is no longer supported. ++ +With this release, if your database is managed by the {productnmame} Operator, updating from {productname} 3.8 -> 3.9 automatically handles upgrading PostgreSQL 10 to PostgreSQL 13. ++ +[IMPORTANT] +==== +Users with a managed database will be required to upgrade their PostgreSQL database from 10 -> 13. +==== ++ +If you do not want the {productname} Operator to upgrade your PostgreSQL deployment from 10 -> 13, you must set the PostgreSQL parameter to `managed: false` in your `quayregistry.yaml` file. For more information about setting your database to unmanaged, see link:https://access.redhat.com/documentation/en-us/red_hat_quay/3/html-single/configure_red_hat_quay/index#operator-unmanaged-postgres[Using an existing Postgres database]. ++ +[IMPORTANT] +==== +* It is highly recommended that you upgrade to PostgreSQL 13. PostgreSQL 10 had its final release on November 10, 2022 and is no longer supported. For more information, see the link:https://www.postgresql.org/support/versioning/[PostgreSQL Versioning Policy]. +==== ++ +If you want your PostgreSQL database to match the same version as your {rhel} system, see link:https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html/deploying_different_types_of_servers/using-databases#migrating-to-a-rhel-8-version-of-postgresql_using-postgresql[Migrating to a RHEL 8 version of PostgreSQL] for {rhel-short} 8 or link:https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/9/html/configuring_and_using_database_servers/using-postgresql_configuring-and-using-database-servers#migrating-to-a-rhel-9-version-of-postgresql_using-postgresql[Migrating to a RHEL 9 version of PostgreSQL] for {rhel-short} 9. + +For more information about the {productname} 3.8 -> 3.9 procedure, see link:https://access.redhat.com/documentation/en-us/red_hat_quay/3.9/html-single/upgrade_red_hat_quay/index#operator-upgrade[Upgrading the {productname} Operator overview] [id="notable-changes-39"] == {productname} technical changes diff --git a/modules/upgrading-postgresql.adoc b/modules/upgrading-postgresql.adoc new file mode 100644 index 000000000..da54dd042 --- /dev/null +++ b/modules/upgrading-postgresql.adoc @@ -0,0 +1,150 @@ +:_content-type: PROCEDURE +[id="upgrading-postgresql"] += Updating {productname} and the {productname} and Clair PostgreSQL databases on {ocp} + +When updating {productname} 3.8 -> 3.9, the Operator automatically upgrades the existing PostgreSQL databases for Clair and {productname} from version 10 to version 13. + +You can update {productname} and the {productname} and Clair PostgreSQL databases on {ocp} by using the *Web Console* UI, or by using the CLI. + +[id="updating-quay-clair-postgresql-db-console"] +== Updating {productname} and the {productname} and Clair PostgreSQL databases using the {ocp} web console + +Use the following procedure to update {productname} and the {productname} and Clair PostgreSQL databases using the {ocp} web console. + +[IMPORTANT] +==== +* This upgrade is irreversible. It is highly recommended that you upgrade to PostgreSQL 13. PostgreSQL 10 had its final release on November 10, 2022 and is no longer supported. For more information, see the link:https://www.postgresql.org/support/versioning/[PostgreSQL Versioning Policy]. +* By default, {productname} is configured to remove old persistent volume claims (PVCs) from PostgreSQL 10. To disable this setting and backup old PVCs, you must set `POSTGRES_UPGRADE_RETAIN_BACKUP` to `True` in your `config.yaml` file. +==== + +.Prerequisites + +* You have installed {productname} 3.6, 3.7, or 3.8 on {ocp}. +* 100 GB of free, additional storage. ++ +During the upgrade process, additional persistent volume claims (PVCs) are provisioned to store the migrated data. This helps prevent a destructive operation on user data. The upgrade process rolls out PVCs for 50 GB for both the {productname} database upgrade, and the Clair database upgrade. + +.Procedure + +. Optional. Back up your old PVCs from PostgreSQL 10 by setting `POSTGRES_UPGRADE_RETAIN_BACKUP` to `True` your `quay-operator` `Subscription` object. For example: ++ +[source,yaml] +---- +apiVersion: operators.coreos.com/v1alpha1 +kind: Subscription +metadata: + name: quay-operator + namespace: quay-enterprise +spec: + channel: stable-3.8 + name: quay-operator + source: redhat-operators + sourceNamespace: openshift-marketplace + config: + env: + - name: POSTGRES_UPGRADE_RETAIN_BACKUP + value: "true" +---- + +. In the {ocp} Web Console, navigate to *Operators* -> *Installed Operators*. + +. Click on the {productname} Operator. + +. Navigate to the *Subscription* tab. + +. Under *Subscription details* click *Update channel*. + +. Select *stable-3.9* and save the changes. + +. Check the progress of the new installation under *Upgrade status*. Wait until the upgrade status changes to *1 installed* before proceeding. + +. In your {ocp} cluster, navigate to *Workloads* -> *Pods*. Existing pods should be terminated, or in the process of being terminated. + +. Wait for the following pods, which are responsible for upgrading the database and alembic migration of existing data, to spin up: `clair-postgres-upgrade`, `quay-postgres-upgrade`, and `quay-app-upgrade`. + +. After the `clair-postgres-upgrade`, `quay-postgres-upgrade`, and `quay-app-upgrade` pods are marked as *Completed*, the remaining pods for your {productname} deployment spin up. This takes approximately ten minutes. + +. Verify that the `quay-database` and `clair-postgres` pods now use the `postgresql-13` image. + +. After the `quay-app` pod is marked as *Running*, you can reach your {productname} registry. + +[id="updating-quay-clair-postgresql-db-cli"] +== Updating {productname} and the {productname} and Clair PostgreSQL databases using the CLI + +Use the following procedure to update {productname} and the {productname} and Clair PostgreSQL databases using the command-line interface (CLI). + +[IMPORTANT] +==== +* This upgrade is irreversible. It is highly recommended that you upgrade to PostgreSQL 13. PostgreSQL 10 had its final release on November 10, 2022 and is no longer supported. For more information, see the link:https://www.postgresql.org/support/versioning/[PostgreSQL Versioning Policy]. +* By default, {productname} is configured to remove old persistent volume claims (PVCs) from PostgreSQL 10. To disable this setting and backup old PVCs, you must set `POSTGRES_UPGRADE_RETAIN_BACKUP` to `True` in your `config.yaml` file. +==== + +.Prerequisites + +* You have installed {productname} 3.6, 3.7, or 3.8 on {ocp}. +* 100 GB of free, additional storage. ++ +During the upgrade process, additional persistent volume claims (PVCs) are provisioned to store the migrated data. This helps prevent a destructive operation on user data. The upgrade process rolls out PVCs for 50 GB for both the {productname} database upgrade, and the Clair database upgrade. + +.Procedure + +. Retrieve your `quay-operator` configuration file by entering the following `oc get` command: ++ +[source,terminal] +---- +$ oc get subscription quay-operator -n quay-enterprise -o yaml > quay-operator.yaml +---- + +. Retrieve the latest version of the {productname} Operator and its channel by entering the following command: ++ +[source,terminal] +---- +oc get packagemanifests quay-operator \ + -o jsonpath='{range .status.channels[*]}{@.currentCSV} {@.name}{"\n"}{end}' \ + | awk '{print "STARTING_CSV=" $1 " CHANNEL=" $2 }' \ + | sort -nr \ + | head -1 +---- ++ +.Example output ++ +[source,terminal] +---- +STARTING_CSV=quay-operator.v3.9.0 CHANNEL=stable-3.9 +---- + +. Using the output from the previous command, update your `Subscription` custom resource for the {productname} Operator and save it as `quay-operator.yaml`. For example: ++ +[source,yaml] +---- +apiVersion: operators.coreos.com/v1alpha1 +kind: Subscription +metadata: + name: quay-operator + namespace: quay-enterprise +spec: + channel: stable-3.9 <1> + name: quay-operator + source: redhat-operators + sourceNamespace: openshift-marketplace + config: + env: + - name: POSTGRES_UPGRADE_RETAIN_BACKUP <2> + value: "true" +---- +<1> Specify the value you obtained in the previous step for the `spec.channel` parameter. +<2> Optional. Back up your old PVCs from PostgreSQL 10 by setting `POSTGRES_UPGRADE_RETAIN_BACKUP` to `True` your `quay-operator` `Subscription` object. + +. Enter the following command to apply the configuration: ++ +[source,terminal] +---- +$ oc apply -f quay-operator.yaml +---- ++ +.Example output ++ +[source,terminal] +---- +subscription.operators.coreos.com/quay-operator created +---- \ No newline at end of file