Skip to content

Remove as much "syncing" from chef and GCP in `gitlab-com` as is possible

Now that we have almost completed web migration, a bulk if not all of our rails configuration should now be running in Kubernetes.

We should look to improve helmfile execution time, reduce the amount of complexity and external dependencies, as well as make things easier to understand by moving the values we sync from chef to instead just be normal values in the appropriate place (values.yaml.gotmpl, or ${environment.yaml.gotmpl} as appropriate). The values we sync from GCP which are largely IP addresses which never changed (as we reserve them in terraform) can also be moved to being entered in directly instead of syncing from GCP each time.

Syncing values from chef and GCP every execution is also causing failures in auto-deploy pipelines, where the syncing silently fails, and we are actually introducing unexpected changes (like removing IP addresses) from LoadBalancer manifests 1 one execution, then adding them back in the next. This can be seen in issue #2066 (closed) and has caused confusion and at least 3 auto-deploy pipeline failures for 1 hour.

This would only cover values we sync from chef/gcp in https://gitlab.com/gitlab-com/gl-infra/k8s-workloads/gitlab-com/-/blob/master/releases/gitlab/values/values-from-external-sources.yaml.gotmpl and not cover the values we sync for gitlab-secrets helm release, for obvious reasons (they are secret) :)

It's possible some values cannot be synced as they are actually secrets but not yet able to be put into a kubernetes secret object. In which case we should leave those as is, but make sure there is a link to the upstream issue to get these moved into Kubernetes secret objects (could they be candidates for infradev?)

Edited by Graeme Gillies