Draft: Prevent registry migrations from running for every release
What does this MR do?
- Not all helm releases are the same:
- Some only change the version of the running GitLab
- Some may change only a single component configuration
- Both of the above create a new release which in turn causes the Container Registry to run a new migration job every single time
- The goal of this commit is to reduce how often we run the registry
migrations to only those that include changes that directly correspond
to the container registry:
- ConfigMap
- The image being used
- We do this by sucking in those values into a sha256sum and appending that to the name of the job
Testing
Enable the use of the registry database:
registry:
database:
enabled: true
Note that this feature is not complete and requires you to have a a set of credentials and database already created. For local development, this can be accomplished by logging into the local postgres and creating a role with password, followed by creating the <release_name>-registry-database-password
secret object. An example of this procedure:
% k create secret generic a-registry-database-password --from-literal=password=foobar
% k exec -it a-postgresql-0 -- /bin/bash Defaulting container name to a-postgresql.
Use 'kubectl describe pod/a-postgresql-0 -n default' to see all of the containers in this pod.
I have no name!@a-postgresql-0:/$ psql -U postgres
postgres=# create role registry with login password 'foobar';
postgres=# create database registry with owner=registry;
Execute a helm upgrade a few times:
- Before this commit, the Jobs will increment as is the current implementation
- With this commit applied, new jobs will cease UNLESS a change is made to the config map, the registry location, or container tag utilized
Note that prior to this, the job name used to be nice and short, example: a-registry-migrations-3
After this is applied, we are taking in nearly a full sha256sum
value, truncated, example: a-registry-migrations-6823289e1884f874a67c6edacd3046ca93a523d81
Related issues
Addresses: gitlab-com/gl-infra/delivery#1890 (closed)
Checklist
See Definition of done.
For anything in this list which will not be completed, please provide a reason in the MR discussion.
Required
-
Merge Request Title and Description are up to date, accurate, and descriptive -
MR targeting the appropriate branch -
MR has a green pipeline on GitLab.com
Expected (please provide an explanation if not completing)
-
Test plan indicating conditions for success has been posted and passes -
Documentation created/updated - No - This feature is currently unsupported and incomplete, therefore no documentation has been added -
Tests added - No - This feature is currently unsupported and incomplete, therefore no tests covering this particular object are added -
Integration tests added to GitLab QA - No - This feature is currently unsupported and incomplete, therefore no tests covering this particular object are added -
Equivalent MR/issue for omnibus-gitlab opened - No - N/A