This service function is really simple: it receives a list of tags, it will loop on them and sending the appropriate request to the Container Registry to delete them.
The main issue is that these requests to the Container Registry can be really slow.
We can easily imagine what happens when the service receives let's say 100K tags to delete. Well, let's summarize it with
One upcoming feature is having Container Registry Cleanup Policies open to all projects. The policies are executed (with a background worker) under a given schedule and each execution will use this service to delete a given list of tags.
To avoid resources starvation, this MR puts an execution time limit to this service.
When the limit is hit, the loop is stopped.
As such, we can have a partial execution which is an accepted outcome.
To have a better control of this execution time limit value, it is implemented as an application setting (container_registry_delete_tags_service_timeout)
The corresponding UI has been added to the container settings in the admin UI (located at /admin/application_settings/ci_cd)
This way, we can update this value directly from the UI
As stated above, this MR is part of a larger effort to limit resources usage during Container Registry Cleanup Policies execution.
This being a deep change from the current behavior, all the limits we are implementing in the larger effort are gated behind a feature flag: container_registry_expiration_policies_throttling. This provides us a safety switch between non throttled executions (current implementation) <-> throttled executions. This switch can be used in the case of a production issue.
This MR being the first of the larger effort, it is the one introducing the feature flag.
To be complete in this MR, the corresponding documentation has been updated with a Caution block to indicate that Cleanup Policies can be partially executed.
[-] Informed Infrastructure department of a default or new setting change, if applicable per definition of done
Security
If this MR contains changes to processing or storing of credentials or tokens, authorization and authentication methods and other items described in the security review guidelines:
[-] Label as security and @ mention @gitlab-com/gl-security/appsec
[-] The MR includes necessary changes to maintain consistency between UI, API, email, or other methods
[-] Security reports checked/validated by a reviewer from the AppSec team
