Keep container registry DB status application setting up to date
What does this MR do and why?
Related to Add observability for self-managed metadata dat... (#425497 - closed).
Context
The GitLab Container Registry is an external/separate service which has its own configuration file, completely independent/separate from GitLab Rails. Therefore, in order to know details about the registry and its configuration in a given GitLab deployment, Rails has no other option than asking the registry for the information it needs. To do this, Rails pings the /v2/
endpoint of the registry API. In the response, there are several special headers which provide insight into the running registry features/configurations.
We use this strategy for collecting metrics from self-managed instances, including the registry version, vendor and supported features. After pinging the registry API, Rails records these values in application_settings
, and then these are included in the Service Ping payload for telemetry. The currently existing attributes are container_registry_version
, container_registry_vendor
and container_registry_features
.
This Change
This MR updates the service that pings the registry (here) so that it persists the value of this header into the new application_settings
column. This service runs daily using a cron job. Here is the full list of steps required:
-
Create the new
container_registry_db_enabled
column on theapplication_settings
(!132133 (merged)); -
Update the client method that pings the Container Registry and read a special header (
GitLab-Container-Registry-Database-Enabled
) that tells us if its metadata database is enabled or not (!132154 (merged)); -
This MR;
-
Add the new application setting to the Service Ping payload.
MR acceptance checklist
This checklist encourages us to confirm any changes have been analyzed to reduce risks in quality, performance, reliability, security, and maintainability.
-
I have evaluated the MR acceptance checklist for this MR.