Skip to content

Gitaly.serviceName is not (consistently) used as documented

Summary

When I set global.gitaly.serviceName, this will neither be the name of the service, nor will it be consistently rendered at all places using the same algorithm. At some places the global serviceName is used, in some places a chart-local one is provided and overrides the global, and at some places (gitlab.gitaly.storage.internal) the different ways of setting the service name are gathered into one mess of a name.

Steps to reproduce

helm install releasename --set global.gitaly.serviceName="some-gitaly-service-name"

Configuration used

global:
  gitaly:
    serviceName: some-gitaly-service-name

Current behavior

# rendered from charts/gitlab/charts/migrations/templates/configmap.yaml
# ...
apiVersion: v1
kind: ConfigMap
data:
  gitlab.yml.erb: |
    production: &base
      repositories:
        storages: # You must have at least a `default` storage path.
          default:
            path: /var/opt/gitlab/repo
            gitaly_address: tcp://releasename-gitaly-0.releasename-gitaly:8075
# rendered from charts/gitlab/charts/gitaly/templates/service.yaml
apiVersion: v1
kind: Service
metadata:
  name: some-gitaly-service-name

Expected behavior

# rendered from charts/gitlab/charts/migrations/templates/configmap.yaml
# ...
apiVersion: v1
kind: ConfigMap
data:
  gitlab.yml.erb: |
    production: &base
      repositories:
        storages: # You must have at least a `default` storage path.
          default:
            path: /var/opt/gitlab/repo
            gitaly_address: tcp://releasename-gitaly-0.some-gitaly-service-name:8075

# rendered from charts/gitlab/charts/gitaly/templates/service.yaml
# ...
apiVersion: v1
kind: Service
metadata:
  name: some-gitaly-service-name

Versions

  • Chart: branch 2-5-stable
  • Platform: kops on AWS
  • Kubernetes:
    • Client: 1.16.3
    • Server: 1.14.8
  • Helm: (helm version)
    • Client: 1.12.0
    • Server: n/a