Deterministically identify the container registry vendor and version on self-managed instances for feature toggling
Problem to solve
In #204839 (closed) we introduced a way to determine the container registry vendor (GitLab or third-party), version, and features. The main purpose was to collect metrics from self-managed instances in order to drive future prioritization and user-experience decisions.
This method was also intended to be used in the future to toggle features based on the registry vendor/version, but we found out that this would not be reliable for self-managed instances. We explored the possibility of having the registry detection running as part of the Omnibus and Charts installs reconfiguration/startup, but we found out that this wouldn't be ideal as admins could still hot-swap the registry (see #204839 (comment 374427684) for additional context).
For this reason, we should pursue a deterministic way of identifying the registry vendor and version on self-managed instances, enabling us to use that information for implementing reliable feature toggling. Ideally, this new approach should replace (or augment) the one introduced in #204839 (closed).
Intended users
- Delaney (Development Team Lead)
- Sasha (Software Developer)
- Devon (DevOps Engineer)
- Sidney (Systems Administrator)
Permissions and Security
- There are no permissions changes required for this change
Documentation
- Update the Container Registry Admin docs
Availability & Testing
What does success look like, and how can we measure that?
- Success looks like we are able to identify the container registry vendor and version on self-managed instances in a deterministic way.