Geo + CNH: mishandling of global.geo.registry.replication.primaryApiUrl
Summary
As found by @jmarquez2 with a customer, when not operating all sides of a Geo deployment via GET, it is entirely unable to configure a Geo secondary via GET. (See also #653 (closed))
The gitlab_charts
Role has a template for the gitlab_values
that is consumed throughout various parts. When using this in conjunction with gitlab_geo
, we've found a mix of a
The problem lies in a few things: an incorrect value used in a template, an inappropriate use of an assumption, and lack of documentation on which values to supply.
Details
First, global.geo.registry.replication.primaryApiUrl
in the gitlab.yml.j2 is set to container_registry_external_url
on the Secondary. This should not be the case, as that value refers to the instance's own FQDN for the Registry service which is consumed as part of the related Ingress object. This should be geo_secondary_registry_url
.
Second, the Redeploy Secondary Charts - Update Registry primary API Url
task that updates it attempts to do a string replace, instead of simply setting the value in the dict
. By doing this, there is no way operate if that value had not been set before. A Primary Geo node will not have had this value set, by the afore mentioned values file.
Lastly, we should ensure that we clearly document that geo_primary_registry_url
should be set to provide this configuration, and not container_registry_external_url
. Swapping these two will result in errors due to invalid values for the Registry's Ingress
object, coming from an invalid value for host
field (host: https://registry.primary.gitlab
).
Versions
GET Version: 1c0cb5c5 (and since Add container registry replication support (!952 - merged))