Customer Problem

As a Quay admin I would like recurring operations for Quay to be automated as much as possible. I do not want to be required to manually intervene when the system is overloaded, subsystems have partial failures nor do I want to own regular maintenance of subsystems like the database.
 

Epic Goal

• Lift off most of the typical day 2 operations of a Quay registry deployment from the admin via the Quay Operator
• Enable declarative ways to manage a more complex Quay deployment with customer/system provided certificates in GitOps-style
• Produce less intermittent failures / restarting pods by using more sequencing logic when initially deploying Quay
• Clean up deleted resources

Why is this important?

• Many Quay components are independently scaled to meet a certain performance requirement
• Admins do not necessarily have the necessary information to make informed decisions about how the scaling for Quay components should be done

Scenarios

1. The Quay Operator intelligently scales Clair instances so the Admin does not have to
2. The Quay Operator intelligently scales Quay mirroring works so the Admin does not have to
3. The Quay Operator takes care of the NooBaa pre-requisite
4. The Quay Operator orchestrates deployment in a way that avoids unnecessary crashlooping of pods
5. The Quay Operator supports deploying Clair in a disconnected environment
6. The Quay Operator does not restart the database unnecessarily
7. The Quay Operator is GitOps-friendly
8. The Quay Operator allows to override aspects of the Quay deployment that cannot be changed / overridden outside of the Operator with mere Kubernetes mechanisms

Acceptance Criteria

• CI - MUST be running successfully with tests automated
• Release Technical Enablement - Provide necessary release enablement details and documents.
• ...

Dependencies (internal and external)

1. ...

Previous Work (Optional):

1. …

Open questions::

1. …

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>