Uploaded image for project: 'Project Quay'
  1. Project Quay
  2. PROJQUAY-1884

Improve Operator Day 2 Management UX

    XMLWordPrintable

Details

    • Quay Operator Day 2 Operations
    • False
    • False
    • To Do
    • QE Needed, Docs Needed, TE Needed, Customer Facing
    • 12
    • 12% 12%
    • Undefined
    • 0

    Description

      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):

      Open questions::

      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>

      Attachments

        Issue Links

          Activity

            People

              Unassigned Unassigned
              DanielMesser Daniel Messer
              Votes:
              0 Vote for this issue
              Watchers:
              2 Start watching this issue

              Dates

                Created:
                Updated: