Allow routing rules to contain shard information
What does this MR do?
This MR updates the gitlab.yml.erb
to allow routing rules to contain shard information.
This change is behind a feature flag and is not released to end-users, but is required for gitlab.com to correctly configure our chef nodes, in particular, the console and deployer nodes.
Test plan
- Set up
kind
cluster
kind create cluster --config examples/kind/kind-no-ssl.yaml
- Update
examples/kind/values-no-ssl.yaml
. Note that redis is omitted since we only have 1 redis configured. The test plan verifies the chart's checker logic to permit routing rules with 3 valid elements.
diff --git a/examples/kind/values-no-ssl.yaml b/examples/kind/values-no-ssl.yaml
index bf8373aef..f92f91d2b 100644
--- a/examples/kind/values-no-ssl.yaml
+++ b/examples/kind/values-no-ssl.yaml
@@ -1,5 +1,9 @@
# Disable SSL altogether
global:
+ appConfig:
+ sidekiq:
+ routingRules:
+ - ["resource_boundary=cpu", "cpu_boundary"]
+ - ['*', 'default', 'default']
hosts:
https: false
- Install gitlab
helm upgrade --install gitlab . --set global.hosts.domain=192.168.1.74.nip.io -f examples/kind/values-base.yaml -f examples/kind/values-no-ssl.yaml
- Verify
config/gitlab.yml
in the sidekiq pod
kubectl exec $(kubectl get pods | grep sidekiq | awk '{print $1}') cat srv/gitlab/config/gitlab.yml
You should see a chunk of the following to show that both old and new formats are rendered:
sidekiq:
log_format: json
routing_rules:
- ["resource_boundary=cpu","cpu_boundary"]
- ["*","default","default"]
Related issues
gitlab-com/gl-infra/scalability#3385 (closed)
Author checklist
See Definition of done.
For anything in this list which will not be completed, please provide a reason in the MR discussion.
Required
-
Merge Request Title and Description are up to date, accurate, and descriptive -
MR targeting the appropriate branch -
MR has a green pipeline on GitLab.com -
When ready for review, follow the instructions in the "Reviewer Roulette" section of the Danger Bot MR comment, as per the Distribution experimental MR workflow
For merge requests from forks, consider the following options for Danger to work properly:
- Consider using our community forks instead of forking your own project. These community forks have the GitLab API token preconfigured.
- Alternatively, see our documentation on configuring Danger for personal forks.
Expected (please provide an explanation if not completing)
-
Test plan indicating conditions for success has been posted and passes -
Documentation created/updated -- the feature is behind a feature flag so the documentation on gitlab rails will be added it is ready to be released for self-hosted users. -
Tests added/updated -
Integration tests added to GitLab QA -
Equivalent MR/issue for omnibus-gitlab opened: gitlab-org/omnibus-gitlab!7512 (merged) -
Equivalent MR/issue for Gitlab Operator project opened (see Operator documentation on impact of Charts changes) -
Validate potential values for new configuration settings. Formats such as integer 10
, duration10s
, URIscheme://user:passwd@host:port
may require quotation or other special handling when rendered in a template and written to a configuration file.
Edited by Sylvester Chin