Commit 1f7d224d authored by Jason Plum's avatar Jason Plum

Merge branch '325-prevent-bad-redis-config' into 'master'

checkConfig: add methods to test for known errors

Closes #325

See merge request charts/gitlab!757
parents a5e4108a d5a32c50
Pipeline #57093062 passed with stages
in 37 minutes and 25 seconds
---
title: Add checkConfig logic to detect known bad configurations
merge_request: 757
author:
type: added
......@@ -3,6 +3,18 @@
This documentation collects reasoning and documentation regard decisions made
regarding the design of the Helm charts in this repository.
## Attempt to catch problematic configurations
Due to the complexity of these charts and their level of flexibility, there are some
overlaps where it is possible to produce a configuration that would lead to an
unpredictable, or entirely non-functional deployment. In an effort
to prevent known problematic settings combinations, we have implemented template logic
designed to detect and warn the user that their configuration will not work.
This replicates the behavior of deprecations, but is specific to ensuring functional configuration.
Introduced in [!757 checkConfig: add methods to test for known errors](https://gitlab.com/charts/gitlab/merge_requests/757)
## Breaking changes via deprecation
During the development of these charts, we occasionally make improvements that require
......
......@@ -9,7 +9,7 @@ The design makes use of multiple templates, providing a modular method of declar
1. The last item in `templates/NOTES.txt` `include`s the `gitlab.deprecations` template from `templates/_deprecations.tpl`.
1. The `gitlab.deprecations` template `include`s further templates in the same file, collecting their outputs (strings) into a `list`.
1. Each individual template handles detection of now errant configuration, and outputs messages informing the user of how to address the change, or outputs nothing.
1. The `gitlab.deprecations` template checks if any messages were collected. If any messages where, it ouputs them under a header of `DEPRECATIONS:` using the `fail` function.
1. The `gitlab.deprecations` template checks if any messages were collected. If any messages were, it outputs them under a header of `DEPRECATIONS:` using the `fail` function.
1. The `fail` function results in the termination of the deployment process, preventing the user from deploying with a broken configuration.
## Template naming
......@@ -32,7 +32,7 @@ chart:
- The `if` statement preceding the message _should not_ trim the newline after it. (`}}` not `-}}`) This ensures the formatting and readability for the user.
- The message should declare which chart, relative to the global chart, that is affected. This helps the user understand where the property came from in the charts, and configuration properties. Example: `gitlab.unicorn`, `minio`, `registry`.
- The message should inform the user of the propery that has been altered / relocated / deprecated, and what action should be taken. Name the property relative to the affected chart. For example, `gitlab.unicorn.minio.enabled` would be referenced as `minio.enabled` because the chart affected by the deprecation is `gitlab.unicorn.
- The message should inform the user of the property that has been altered / relocated / deprecated, and what action should be taken. Name the property relative to the affected chart. For example, `gitlab.unicorn.minio.enabled` would be referenced as `minio.enabled` because the chart affected by the deprecation is `gitlab.unicorn`.
Example message:
......@@ -44,4 +44,4 @@ gitlab.unicorn:
## Activating new deprecations
Once a template has been defined, and logic placed within it for the detection of affected properties, activiating this new template is simple. Simple add a line beneath `add templates here` in the `gitlab.deprecations` template, according to the format presented.
Once a template has been defined, and logic placed within it for the detection of affected properties, activating this new template is simple. Simple add a line beneath `add templates here` in the `gitlab.deprecations` template, according to the format presented.
......@@ -247,6 +247,14 @@ See the documentation of the [deprecations template][] for further information o
[deprecations template]: deprecations.md
## Attempt to catch problematic configurations
Due to the complexity of these charts and their level of flexibility, there are some overlaps where it is possible to produce a configuration that would lead to an unpredictable, or entirely non-functional deployment. In an effort to prevent known problematic settings combinations, we have implemented template logic designed to detect and warn the user that their configuration will not work
See the documentation of the [checkConfig template][] for further information on the design, functionality, and how to add new configuration checks.
[checkConfig template][checkconfig.md]
## Verifying registry
In development mode, verifying Registry with Docker clients can be difficult. This is partly due to issues with certificate of
......
......@@ -34,3 +34,5 @@ WARNING: Automatic TLS certificate generation with cert-manager is disabled and
{{- end -}}
{{/* run deprecations */}}
{{ include "gitlab.deprecations" . }}
{{/* run checkConfig */}}
{{ include "gitlab.checkConfig" . }}
{{/*
Template for checking configuration
The messages templated here will be combined into a single `fail` call. This creates a means for the user to receive all messages at one time, instead of a frustrating iterative approach.
- `define` a new template, prefixed `gitlab.checkConfig.`
- Check for known problems in configuration, and directly output messages (see message format below)
- Add a line to `gitlab.checkConfig` to include the new template.
Message format:
**NOTE**: The `if` statement preceding the block should _not_ trim the following newline (`}}` not `-}}`), to ensure formatting during output.
```
chart:
MESSAGE
```
*/}}
{{/*
Compile all warnings into a single message, and call fail.
Due to gotpl scoping, we can't make use of `range`, so we have to add action lines.
*/}}
{{- define "gitlab.checkConfig" -}}
{{- $messages := list -}}
{{/* add templates here */}}
{{- $messages := append $messages (include "gitlab.checkConfig.redis.both" .) -}}
{{- /* prepare output */}}
{{- $messages := without $messages "" -}}
{{- $message := join "\n" $messages -}}
{{- /* print output */}}
{{- if $message -}}
{{- printf "\nCONFIGURATION CHECKS:\n%s" $message | fail -}}
{{- end -}}
{{- end -}}
{{/* Check configuration of Redis - can't have both redis & redis-ha */}}
{{- define "gitlab.checkConfig.redis.both" -}}
{{- if and .Values.redis.enabled (index .Values "redis-ha" "enabled") -}}
redis: both providers
It appears that `redis.enabled` and `redis-ha.enabled` are both true.
this will lead to undefined behavior. Please enable only one.
{{- end -}}
{{- end -}}
{{/* END gitlab.checkConfig.redis.both */}}
Markdown is supported
0% or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment