FinOps Chart Schema

[HMetcalfeW]

Interested in the team's feedback on adding a schema to our Helm Chart. The initial generation was relatively straightforward, but as our chart evolves, this file will require ongoing maintenance. If we think this is too much maintenance, then I'm happy to table it, but believe it can pay long-term dividends. This first iteration is lax because it lacks required fields.

The practice is fairly common in the Bitnami Charts community. There's a great blog post on the motivations behind creating a Values schema and the various checks it allows.

• Requirement checks. Example: An API_KEY environment variable is set
• Type validation. Example: The image tag is a string such as "1.5" and not the number 1.5
• Range validation. Example: The value for a CPU utilization percentage key is between 1 and 100
• Constraint Validation. Example: The pullPolicy is IfNotPresent, Always, or Never; A URL has the format http(s)://:

Since schema checks are run on all Helm commands (template, lint, upgrade, install), this helps prevent customer values from drifting too far between versions and clearly defines what values are/are not allowed.

Example Helm output using a number for clusterId
helm lint . --set global.clusterId=1234

- at '/global/clusterId': got number, want string

https://helm.sh/docs/helm/helm_lint/

[thomasvn]

I'm open to trying this out! Especially if we just start with type validation in the schema.

My only minor hesitation is that any time we need to make fixes/updates to this schema, it will need to be accompanied by:

• A newly built finops-agent image & version
• An updated Chart.yaml in the Kubecost helm chart, to consume this new subchart