Epic Goal

• Leverage the Operator in geo-replication deployments of Quay among multiple cluster

Why is this important?

• Geo-rep is one of the key differentiators for Quay
• The operator is the preferred way of running Quay
• The operator currently does not support geo-replication

Scenarios

1. A customer installs Quay (with Clair, Mirroring and Builders potentially) on 3 separate OpenShift clusters, in 3 separate geographies, leveraging a shared external databases for Quay and Clair, a shared external Redis instance/cluster and 3 separate external object storages
2. A customer updates above mentioned Quay setup and is required to scale all but one of the Quay instances down in order to run the first database schema migration
3. A customer uses an external global load balancing mechanism like a shared global IP for all Quay end points and another one for all Clair endpoints or a geo-aware DNS load-balancer
4. Quay and Clair need to be able to identify themselves with the FQDN of the global load balancers, not that of the individual Route objects on the clusters
5. A customer uses GitOps to distribute the various QuayRegistry configurations to the cluster

Acceptance Criteria

• A customer can deploy Quay with a custom SERVER_HOSTNAME that is different from the name of Route that is being generated
• A customer can scale down a quay deployment in case an update runs in another cluster using the same shared database
• A customer can override the preferred storage backend for each individual quay deployment in a cluster
• CI - MUST be running successfully with tests automated
• Release Technical Enablement - Provide necessary release enablement details and documents.
• ...

Dependencies (internal and external)

1. Clair deployments with custom configuration and external databases

Open questions:

1. Do we need a special geo-rep mode of the operator?

Done Checklist

• CI - CI is running, tests are automated and merged.
• Release Enablement <link to Feature Enablement Presentation>
• DEV - Upstream code and tests merged: <link to meaningful PR or GitHub Issue>
• DEV - Upstream documentation merged: <link to meaningful PR or GitHub Issue>
• DEV - Downstream build attached to advisory: <link to errata>
• QE - Test plans in Polarion: <link or reference to Polarion>
• QE - Automated tests merged: <link or reference to automated tests>
• DOC - Downstream documentation merged: <link to meaningful PR>