| Addshore | |
| Feb 1 2022, 11:45 AM |
| F34939301: image.png | |
| Feb 1 2022, 11:45 AM |
In the call we had today we identified somewhere in our helmfile setup where we have a defined but unused values.
Rather than looking at this by hand we should investigate linting options that may be able to detect this sort of thing automatically for us.
We should also remove any defined by unused values that we may already have.
| Status | Subtype | Assigned | Task | ||
|---|---|---|---|---|---|
| Resolved | None | T297603 [INITIATIVE] Deploy a production environment for wikibase.cloud | |||
| Resolved | Tarrow | T299502 [EPIC] Pre-launch version of Wikibase.cloud goes live | |||
| Resolved | Tarrow | T300143 Refactoring's around multiple helmfile deployments 🟩 | |||
| Resolved | Tarrow | T300621 Investigate linting of our helmfile setup to detect defined but unused values 🟩 |
TL;DR it's complicated. Either don't attempt to automate this, or add JSON schemas for values to all our charts.
This turned out to be quite tricky. Any helm chart that contains a values.schema.json (docs) file, e.g. the mariadb one, gets validated against that schema when running helmfile diff|apply|lint|.... Unfortunately schema validation does not necessarily mean detecting unused variables. The linter will only complain if the schema has additionalProperties: false set.
I tried this out for our certificates chart. I added a super minimal values.schema.json file to the chart's directory:
{
"$schema": "https://json-schema.org/draft-07/schema#",
"additionalProperties": false,
"properties": {
"certificates": {
"type": "array"
}
},
"required": [
"certificates"
],
"title": "Values",
"type": "object"
}Then when I add an unused value, e.g. potato: yes to staging/certificates.values.yaml.gotmpl and run helmfile -e staging lint I get a nice error:
==> Linting ../../charts/certificates [INFO] Chart.yaml: icon is recommended [ERROR] values.yaml: - (root): Additional property potato is not allowed
Adding schemas for all our custom charts would be quite a lot of effort though and detecting unused values of 3rd party charts is out of our control for the most part. Schema generators might be an option for our own charts, e.g. something like this.
I didn't find any good alternative solutions. There are some related issues, but they either didn't go anywhere or point to the JSON schema solution:
I'm also unsure whether it would make sense to run such a linter in CI. Schema violations cause helmfile diff and helmfile apply to error immediately, so this is one of those things that would rarely even make it into the code and would be detected by the person writing or testing the code. Also, helmfile lint currently errors for recent helm versions in our repository due to a problem with the adminer chart we use.
Thank you @Jakob_WMDE for looking into this. We probably should take a decision as a group for what to do next from here based on this. I will unassigned myself
IMHO, this seems like a lot of extra work for a very limited bang for the buck. I'm glad we found this out and seemingly have a roadmap to also doing it for the entire repo at some point. But I don't think we should do this now.
My reasoning being:
Do we create the ticket for the backlog now either way and then in the sprint planning decide the priority off this?
I also think that this would be of limited value given the effort required.
I'm not sure we even have a clear path towards it for our 3rd party charts; we'd have to fork them in the event that they are missing either values.schema.json or haven't set additionalProperties: false.
One possible alternative solution; that is still a lot of effort would be rolling our own test for this. If we really wanted to perhaps we could contrive something.
I think in general the outcome of this investigation is that we don't want to do this right now.