Grant "rename lease" on existing repositories that are in the process of a rename operation
Context
Following from #895 (closed), We implemented a rename lease on the repository to be renamed to (i.e the target repository). That lease allowed us to prevent other existing repositories from laying a claim on the new target repository path when (the target path is) already leased by an existing repository.
Example, For a rename lease acquired by base-repository /my-group/my-sub-group/old-name
to name new-name
a lease with
- key :
registry:api:{repository-lease:my-group:hash(/my-group/my-sub-group/new-name)}
- and value
{"granted_to":"/my-group/my-sub-group/old-name", "lease_type":"rename", "path":"/my-group/my-sub-group/new-name"}
is granted
That solved the issue of race conditions in acquiring leases on a specific name between different projects.
Note: Rename leases are currently designed to support project renaming from Gitlab rails, and as such they are only to be called by rails when renaming a project, referencing the project-path/base-repository of the project in the request parameter
Problem
We now want to introduce the functionality to allow us to be able to decide which pre-exisiting (origin) repositories (and all its sub-repositories) are temporarily "locked" because of a rename operation. The existing lease implementation in #895 (closed) only allows us to know that a rename path is taken and can not be re-used for the duration of the lease.
The new functionality discussed here will be used when tackling #925 (closed) to make sure that an origin repository (and any of its sub-repositories) is not in an ongoing rename or has not initiated one (by way of a rename lease) before proceeding to run normal registry CRUD operations (e.g pull, push, delete)
Pain points
-
To be able to discern which origin repositories (i.e existing repositories) have leases on them we may need to create a pair-lease to the target repository lease already created. The pair lease will need to reference the repository-path of the origin as the key and expire the same time as the target repository lease. This new lease will allow us to lookup existing repositories with ongoing leases and prevent doing any CRUD operations on the repositories under them. -
When a regular request comes to the registry we are currently unable to tell if the request referenced repository is the base repository and we are also unable to extrapolate the project path of the repository. This leads to a problem where: - We can't discern if an origin repository lease exist with an exact match of the repository path referenced in a request with a key stored in redis, as the repository referenced in a request could be a sub-repository as opposed to the base repository. This leads to not beign able to tell if CRUD operations are locked or not for the specific repository in the request. Take the example where:
We have created an origin lease for the base project path
/my-group/my-sub-group
and we receive a push request to the repository path/my-group/my-sub-group/name1/name2
. We have no way of knowing if the base-path (which could be a base repository or not ) of/my-group/my-sub-group/name1/name2
is/my-group/my-sub-group
or/my-group/my-sub-group/name1
or even/my-group/my-sub-group/name1/name2
. Further leading us to not knowing which path the (origin lease) may have been keyed under
The lease could have been stored under any of the following keys /my-group/my-sub-group
, /my-group/my-sub-group/name1/name2
, /my-group/my-sub-group/name1
. But we want to match prevent CUD operations on /my-group/my-sub-group/*
Solution
Grant the rename lease for existing repositories based on the the project path specified in the JWT token: gitlab#406795 (closed)
Task
-
Introduce a new rename lease that pairs with the existing one in #895 (closed). This new rename lease will serve to allow us to be able to decide which already existing (origin) repositories (and all its sub-repositories) are temporarily "locked" because of a rename operation.