Introduce the new cleanup tags service that uses the new API
🔥 Problem
Currently, cleanup policies are slow for a main technical issue: getting the creation timestamp of a single tag is a Container Registry API request.
As we can imagine, the more tags we need to process, the more pings to the Container Registry we're going to trigger.
We improved the situation around this using caching in !69459 (merged).
Proposal
The new service will need to implement exactly the same filters as the old path service. In addition, it will need to return the same response structure so that the change is completely transparent to the callers of these services. The new service can drop a few optimizations we have in the old path:
- Truncation. We don't need to truncate anymore. Simply get a certain amount of pages and use that as the current truncated list.
- Alternative: walk through pages until a certain amount of tags to delete is hit.
- Redis caching. The whole purpose of the new API: fetching the creation timestamp is not a performance anymore = we don't need to cache it anymore.
In addition:
- The new service will basically loop through pages. That's great, however, we're still limited in time as this is called by a background job. As such, limit the execution time.
- The new API uses a more accurate way to compute the
created_at
andupdated_at
. As such, the service should considerupdated_at
and fall back tocreated_at
. Basically:updated_at || created_at
. See container-registry#757 (comment 1067919936) for the full explanations.
🔬 Implementation details
See the implementation details here: &8379 (comment 1025779804)
Edited by David Fernandez