Goal:

This feature will provide greater control over storage allocation, aligning with enterprise storage strategies and improving performance. It addresses the current limitations of using default storage classes, which can lead to suboptimal choices, especially for database operations.

Background

Currently, Quay deployments on OpenShift using the operator utilize the default StorageClass for Quay and Clair, and the default ObjectStorage class for S3 object storage. In clusters with multiple storage classes, this can lead to the selection of suboptimal storage options, especially for database operations.

Clusters often have various storage classes, including NFS, NAS, ODF, and SAN storage, each with different attributes in terms of speed, price, and availability. Manually switching the default StorageClass before or after deployment is a risky workaround and doesn't align well with GitOps/IaC approaches.

Acceptance Criteria

• Users can customize the StorageClass for PVCs via an override in the QuayRegistry CR, similar to existing volume size overrides.

• The override option is available for all managed Quay components (Quay, Clair, object storage).

• If no override is specified, the operator uses the default StorageClass.

• The feature is documented in the Quay Operator deployment guide.

• The feature works with existing Quay Operator deployments without breaking backward compatibility.

User Story

• As a Quay administrator, I can use the Operator to customize the Kubernetes StorageClass used for provisioning PVCs, allowing me to choose different storage backends for various databases and components associated with Quay.
• As a Quay administrator, I want to be able to specify the StorageClass used by managed Quay components (such as Quay, Clair, and object storage) when deploying Quay on OpenShift using the operator. This will allow me to select the most suitable storage option from the various choices available in my on-premises datacenter cluster.