Auto-pruning policies for repositories

Customer Problem: In many customer environments the most active clients of a central registry are automated systems like CI / CD pipelines producing new content. With strict consumption quotas in place it is possible to hit outage scenarios caused by quota limit being reached which requires human intervention to be resolved The intervention often looks the same, for example deleting the oldest images to free up space. In case of automated systems these situations will be hit regularly and it is desireable to avoid them from the start with automatic remediation.

Goal: Help Quay tenants to stay below the quota by automatically pruning content based on user-defined criteria.

Why is this important

• enabling storage quotas requires human intervention in order to stay below the quota or remediate quota excess conditions
• automated systems usually don't have clean up built in, they simply produce a never ending stream of new content
• especially development environments produce a lot of content which is versioned according to semver rules providing an opportunity to use semantics to determine old content

Prioritized deliverables (work-in-progress):

1. As a Quay organization owner I can define auto-pruning policies at the level of the organization to target one or more repositories in that organizations 
2. As a Quay repository owner I can define auto-pruning policies at the level of the repository to target one or more of my repositories in that organization
3. Auto-pruning policies can be event-driven, e.g. reaching a certain threshold of the storage quota or permanently running
4. Multiple pruning policies (e.g. for the same event) can be defined and are processed in order of their creation
5. Pruning policies can have different criteria that define when an image should be deleted: time-based rules and tag-based rules
6. Time-based rules cause the oldest images to be deleted first: either by creation date or last pull date
7. Tag-based rules cause the oldest images to be deleted first according to semantic version information found in the tag, lowest version first
8. As a user I can see a warning telling me that until we have insights on where the images is used (deployed as a pod or referenced by a CR) the automated pruning might cause issues on the cluster side.
9. As a user I can define a maximum amount of tags / images inside a repo to ensure that for example only the 5 most recent versions are kept and the rest gets deleted automatically.
10. original customer RFE: https://issues.redhat.com/browse/QUAY-1145

Dependencies (internal and external):

• PROJQUAY-302
• We need a pull counter in Quay

Estimate (XS, S, M, L, XL, XXL):  TBD

Previous Work: 

• TBD

Open questions:

• should we consider pruning policies to be focussed on retention rather than deletion?