[go: up one dir, main page]
Skip to content

Allow configuring redis database number in values.yaml

Gabriele Pongellirequested to merge
gpongelli/gitlab-chart:redis-add-database into master
  • Please check this box if this contribution uses AI-generated content (including content generated by GitLab Duo features) as outlined in the GitLab DCO & CLA. As a benefit of being a GitLab Community Contributor, you can request access to GitLab Duo.

What does this MR do?

Allows users of the helm chart to configure a redis:database. This gets added to the Redis URL.

In case of deploying redis as a subchart into the same gitlab's namespace, this change is not useful because redis server is not shared with other applications.

Considering only the use case where this helm chart is deployed on a cluster and the admin want to use external redis database, before this MR it was only possible to use database 0 (redis default database) without any way to select a different database. It can be a case where database 0 was already in use by other application and gitlab could not be configured to use external redis.

Adding this field into helm chart let admin choose which redis database of the 16 available the gitlab instance should use, without affecting already deployed application.

Manual test steps

  1. setup a minikube cluster with minikube start --nodes 2 --cpus='8' --memory='8g'
  2. to fix an issue with Minikube in multi-node cluster and persistent volumes, as suggested by this issue, I've then executed
minikube addons disable storage-provisioner
minikube addons disable default-storageclass
minikube addons enable volumesnapshots
minikube addons enable csi-hostpath-driver
kubectl patch storageclass csi-hostpath-sc -p '{"metadata": {"annotations":{"storageclass.kubernetes.io/is-default-class":"true"}}}'
  1. then, to have a working deployment on local cluster, the command run on the development branch is helm upgrade --install gitlab . --timeout 600s --set global.image.pullPolicy=Always --set global.hosts.domain=example.com --set global.hosts.externalIP=10.10.10.10 --set certmanager-issuer.email=me@example.com --set global.minio.enabled=false --set global.appConfig.lfs.enabled=false --set global.appConfig.artifacts.enabled=false --set global.appConfig.upload.enabled=false --set global.appConfig.packages.enabled=false --set nginx-ingress.controller.replicaCount=1 --set prometheus.install=false --set registry.enabled=false --set gitlab-runner.install=false --set gitlab-toolbox.enabled=false (same changes can be stored directly into values.yaml file to then run a shorter command)
  2. be sure that all the pods are deployed correctly with this configuration, that still does not involve redis change, running kubectl get pods and checking that all pods are in READY state (it can take some time, depending on local machine)
  3. run then the command that do same deply switching the redis database helm upgrade --install gitlab . --timeout 600s --set global.image.pullPolicy=Always --set global.hosts.domain=example.com --set global.hosts.externalIP=10.10.10.10 --set certmanager-issuer.email=me@example.com --set global.minio.enabled=false --set global.appConfig.lfs.enabled=false --set global.appConfig.artifacts.enabled=false --set global.appConfig.upload.enabled=false --set global.appConfig.packages.enabled=false --set nginx-ingress.controller.replicaCount=1 --set prometheus.install=false --set registry.enabled=false --set gitlab-runner.install=false --set gitlab-toolbox.enabled=false --set global.redis.database=4 (same changes can be stored directly into values.yaml file to then run a shorter command)
  4. be sure again that all the pods are deployed correctly with this new configuration, that does involve redis database change, running kubectl get pods and checking that all pods are in READY state (it can take some time, depending on local machine)

Related issues

Closes #5894 (closed)

Author checklist

For general guidance, please follow our Contributing guide.

Required

For anything in this list which will not be completed, please provide a reason in the MR discussion.

  • Merge Request Title and Description are up to date, accurate, and descriptive.
  • MR targeting the appropriate branch.
  • MR has a green pipeline.
  • Documentation created/updated.
  • Tests added/updated, and test plan for scenarios not covered by automated tests.
  • Equivalent MR/issue for omnibus-gitlab opened.

Reviewers checklist

Edited by Clemens Beck

Merge request reports