Add application setting to track container registry has DB status
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 adds a new application setting that will allow us to track (through Service Ping) how many self-managed instances have a Container Registry with the metadata database enabled (a specific configuration on the registry side). Here is the full list of steps required:
-
Create the new
container_registry_db_enabled
column on theapplication_settings
(this MR); -
Update the client method that pings the Container Registry (here) and read a special header (
GitLab-Container-Registry-Database-Enabled
) that tells us if its metadata database is enabled or not; -
Update 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; -
Add the new application setting to the Service Ping payload.
Database migrations up/down
Up
main: == [advisory_lock_connection] object_id: 228420, pg_backend_pid: 17383
main: == 20230919123305 AddContainerRegistryDbEnabledToApplicationSettings: migrating
main: -- add_column(:application_settings, :container_registry_db_enabled, :boolean, {:null=>false, :default=>false})
main: -> 0.0078s
main: == 20230919123305 AddContainerRegistryDbEnabledToApplicationSettings: migrated (0.0145s)
main: == [advisory_lock_connection] object_id: 228420, pg_backend_pid: 17383
ci: == [advisory_lock_connection] object_id: 228740, pg_backend_pid: 17385
ci: == 20230919123305 AddContainerRegistryDbEnabledToApplicationSettings: migrating
ci: -- add_column(:application_settings, :container_registry_db_enabled, :boolean, {:null=>false, :default=>false})
ci: -> 0.0124s
ci: == 20230919123305 AddContainerRegistryDbEnabledToApplicationSettings: migrated (0.0372s)
ci: == [advisory_lock_connection] object_id: 228740, pg_backend_pid: 17385
Down
main: == [advisory_lock_connection] object_id: 228100, pg_backend_pid: 16524
main: == 20230919123305 AddContainerRegistryDbEnabledToApplicationSettings: reverting
main: -- remove_column(:application_settings, :container_registry_db_enabled, :boolean, {:null=>false, :default=>false})
main: -> 0.0059s
main: == 20230919123305 AddContainerRegistryDbEnabledToApplicationSettings: reverted (0.0128s)
main: == [advisory_lock_connection] object_id: 228100, pg_backend_pid: 16524
ci: == [advisory_lock_connection] object_id: 228060, pg_backend_pid: 16946
ci: == 20230919123305 AddContainerRegistryDbEnabledToApplicationSettings: reverting
ci: -- remove_column(:application_settings, :container_registry_db_enabled, :boolean, {:null=>false, :default=>false})
ci: -> 0.0059s
ci: == 20230919123305 AddContainerRegistryDbEnabledToApplicationSettings: reverted (0.0246s)
ci: == [advisory_lock_connection] object_id: 228060, pg_backend_pid: 16946
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.