Discussion: What has to be true to roll out the next-gen container registry to self-managed?
Context
Throughout the past year, the Package group has been working to create and deploy the next generation of the Container Registry to GitLab.com. In Gradual migration plan for GitLab.com Container... (#374 - closed) we identified a plan to do so.
Problem to solve
The problem is that self-managed customers will not have the new registry code. This means that many of the planned performance improvements, UI updates, and other bugs, will not be resolved for self-managed customers. It also means that the codebase will have to have logic that routes to functionality based on the version of the container registry a customer is using, which can get complicated over time.
Discussion
As a team, we've delayed the conversation for the self-managed rollout to:
- Focus on the GitLab.com migration
- We know that we will want to have a period of time with the GitLab.com container registry running at scale prior to rolling it out to self-managed customers. Why? Because self-managed customers don't continually regularly update their applications. So introducing a bug may have a long-lasting effect or at least cause them to change their standard workflows.
- We haven't yet agreed on an upgrade strategy.
So, this issue is to discuss, what has to be true for us to start the rollout to self-managed. Some questions to help start the discussion:
- What metrics for the GitLab.com container registry will be used to determine readiness? Error budget? The number of bugs open/closed? Test coverage?
- Will we support an online or offline (read-only) migration plan?
- Are there additional observability features that we need to add?
- Do we need to test on the most frequently used architecture setups?
- Do we have specific performance thresholds?