Rename a base container repository (and all sub-repositories, if any) (PART 1/3)
Context
This follows up from the investigation carried out in gitlab#381392 (closed), on "Allowing renaming projects with container registry data"
Problem
In order to perform a container repository rename (which could stem from a project rename) as described in gitlab#381392 (closed), we need to be able to update the base repository (and all sub-repositories (if any)) for a given path. There is no way we can do this today using the registry API.
This issue only focuses on renaming the necessary repositories within the metadata database and does not implement locking the resources affected in the rename, as such this is an incomplete (first iteration) "rename" process because it leaves room for rename conflicts. For data integrity reasons, the new endpoint should not be used in production environments until #895 (closed) and #897 (closed) are completed
Task
-
Extend the container registryAPI-GitLab-V1 with a new operation of the form: PATCH /gitlab/v1/repositories/<path>/
that performs an atomic bulk update for a base repository (name
andpath
) and all (that existing sub-repositories (path
s)) under the requestedpath
. This operation should accept changes to repository attributes, starting with theirname
.-
Access to this route should be restricted to internal (Rails) use only. -
Before attempting the update in the registry database, the operation should start by ensuring that no repository with path my-group/new-name
ORmy-group/new-name/%
exist. Otherwise, a409 Conflict
should be returned. -
For scalability and performance reasons, this feature will start by being limited to projects with no more than 1000 container repositories. For GitLab.com, this covers 99.98% of all projects (source). We can then increase this later based on metrics and pending a decision in https://gitlab.com/gitlab-org/gitlab/-/issues/357014 (internal). Attempting to update more than 1000 repositories (base and sub-repositories) should yield a 422 Unprocessable Entity
response. -
The endpoint should accept a "dry-run" option on the same PATCH /gitlab/v1/repositories/<path>/
API operation.This option should lead to a check that ensures the target repositories name/path is not yet taken on the registry without performing the rename. If the target name/path is already taken a409 Conflict
response should be returned.In a future iteration (PART 2/3 #895 (closed)) we will extend the "dry-run" option to also acquire a special "rename lease" on the repository that needs to be renamed, stopping any conflicting write operations for a short period of time
-