Chapter 5. Upgrading Quay using the Quay Operator
The Quay Operator follows a synchronized versioning scheme, which means that each version of the Operator is tied to the version of Quay and its components which it manages. There is no field on the
QuayRegistry custom resource which sets the version of Quay to deploy; the Operator only knows how to deploy a single version of all components. This scheme was chosen to ensure that all components work well together and to reduce the complexity of the Operator needing to know how to manage the lifecycles of many different versions of Quay on Kubernetes.
5.1. Operator Lifecycle Manager
The Quay Operator should be installed and upgraded using the Operator Lifecycle Manager (OLM). When creating a
Subscription with the default
approvalStrategy: Automatic, OLM will automatically upgrade the Quay Operator whenever a new version becomes available.
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 desireable, then the
Manual approval strategy should be selected.
5.2. Upgrading Quay by upgrading the Quay Operator
The general approach for upgrading installed Operators on OpenShift is documented at Upgrading installed Operators.
5.2.1. Upgrading Quay
From a Red Hat Quay point of view, to update from one minor version to the next, for example, 3.4 → 3.5, you need to actively change the update channel for the Quay Operator.
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 Operator will upgrade automatically to the newest
z stream, resulting 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.
5.2.2. Changing the update channel for an Operator
The subscription of an installed Operator specifies an update channel, which is used to track and receive updates for the Operator. To upgrade the Quay Operator to start tracking and receiving updates from a newer channel, change the update channel in the
Subscription tab for the installed Quay Operator. For subscriptions with an
Automatic approval strategy, the upgrade begins automatically and can be monitored on the page that lists the Installed Operators.
5.2.3. Manually approving a pending Operator upgrade
If an installed Operator has the approval strategy in its subscription set to
Manual, when new updates are released in its current update channel, the update must be manually approved before installation can begin. If the Quay Operator has a pending upgrade, this status will be displayed in the list of Installed Operators. In the
Subscription tab for the Quay Operator, you can preview the install plan and review the resources that are listed as available for upgrade. If satisfied, click
Approve and return to the page that lists Installed Operators to monitor the progress of the upgrade.
The following image shows the
Subscription tab in the UI, including the update
Approval strategy, the
Upgrade status and the
The list of Installed Operators provides a high-level summary of the current Quay installation:
5.3. Upgrading a QuayRegistry
When the Quay Operator starts up, 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:
status.currentVersionis unset, reconcile as normal.
status.currentVersionequals the Operator version, reconcile as normal.
status.currentVersiondoes not equal the Operator version, check if it can be upgraded. If it can, perform upgrade tasks and set the
status.currentVersionto the Operator’s version once complete. If it cannot be upgraded, return an error and leave the
QuayRegistryand its deployed Kubernetes objects alone.
5.4. Enabling new features in Quay 3.5
5.4.1. Console monitoring and alerting
The support for monitoring of Quay 3.5 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 re-install it for all namespaces, once the upgrade has taken place.
5.4.2. OCI and Helm support
Support for Helm and OCI artifacts is now enabled by default in Red Hat Quay 3. 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:
FEATURE_GENERAL_OCI_SUPPORT: true FEATURE_HELM_OCI_SUPPORT: true
5.5. 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:
"quay-operator/migrate": "true"to the
$ oc edit quayecosystem <quayecosystemname>
metadata: labels: quay-operator/migrate: "true"
Wait for a
QuayRegistryto be created with the same
QuayEcosystemwill be marked with the label
status.registryEndpointof the new
QuayRegistryis set, access Quay and confirm all data and settings were migrated successfully.
When you are confident everything worked correctly, you may delete the
QuayEcosystemand Kubernetes garbage collection will clean up all old resources.
5.5.1. Reverting QuayEcosystem Upgrade
If something goes wrong during the automatic upgrade from
QuayRegistry, follow these steps to revert back to using the
QuayRegistryusing either the UI or
$ kubectl delete -n <namespace> quayregistry <quayecosystem-name>
If external access was provided using a
Route, change the
Routeto point back to the original
Serviceusing the UI or
QuayEcosystem was managing the Postgres database, the upgrade process will migrate your data to a new Postgres database managed by the upgraded Operator. Your old database will not be changed or removed but Quay will no longer use it once the migration is complete. If there are issues during the data migration, the upgrade process will exit and it is recommended that you continue with your database as an unmanaged component.
5.5.2. Supported QuayEcosystem Configurations for Upgrades
The Quay Operator will report errors in its logs and in
status.conditions if migrating a
QuayEcosystem component fails or is unsupported. All unmanaged components should migrate successfully because no Kubernetes resources need to be adopted and all the necessary values are already provided in Quay’s
Ephemeral database not supported (
volumeSize field must be set).
Nothing special needed.
Route access supported for automatic migration. Manual migration required for other methods.
LoadBalancerwithout custom hostname: After the
QuayEcosystemis marked with label
"quay-operator/migration-complete": "true", delete the
metadata.ownerReferencesfield from existing
Servicebefore deleting the
QuayEcosystemto prevent Kubernetes from garbage collecting the
Serviceand removing the load balancer. A new
Servicewill be created with
<QuayEcosystem-name>-quay-app. Edit the
spec.selectorof the existing
Serviceto match the
spec.selectorof the new
Serviceso traffic to the old load balancer endpoint will now be directed to the new pods. You are now responsible for the old
Service; the Quay Operator will not manage it.
Ingresswith custom hostname: A new
LoadBalancerwill be created with
<QuayEcosystem-name>-quay-app. Change your DNS settings to point to the
status.loadBalancerendpoint provided by the new
Nothing special needed.
QuayEcosystem did not have a managed object storage component, so object storage will always be marked as unmanaged. Local storage is not supported.
Nothing special needed.