Schema validation to catch typos etc!

[consideRatio]

I just learned about JSONSchema's additionalProperties! It allows us to declare that we don't accept values besides those declared in the schema for a certain object with declared properties.

This can enable what we have wanted for a very long time, something that spots typos! Since we now have a values.schema.json file that covers almost all properties on all declared objects, we can actually set additionalProperties: false on those objects.

Example

If a helm chart contained the following values.schema.json file, and the user provided the values.yaml file below, it would raise an error because it detected a unknown property - the misspelled fullnameOveride.

# a YAML representation of the values.schema.json file to ship with a Helm chart
# and used to validate all the Helm chart's passed values
#
$schema": http://json-schema.org/draft-07/schema#
type: object
additionalProperties: false
required:
  - fullnameOverride
properties:
  fullnameOverride:
    type: [string, "null"]

# a values.yaml file to be validated by the schema, as automated by `helm upgrade` etc
fullnameOveride: my-test-name

Action points

What do you think about making this part of the 1.0.0 release where we introduce schema validation in the first place? I think it would be good to introduce this together with the other schema validation logic that only catches setting invalid data formats on known properties etc.

• Go through the schema.yaml file and set additionalProperties: false wherever we feel confident we cover all properties.
• Trial this out in a 1.0.0 release candidate

Related

• values.schema.json ships with chart and configuration reference now covers all options #2033

Technical notes

• Someone passes values to access them from the hub pod will be required to do it under custom. A sensible practice to enforce, it is documented to be used for that already.
• I'm able to debug loads of issues by using lint-and-validate-values.yaml and the validation script in tools. I realize quickly we must allow additionalProperties whenever we have something like labels, annotations, nodeSelector, resources, etc where there can show up user specific values or in other cases when we don't have a schema representing all of the k8s details such as for the livenessProbes and such.
• I consider this a breaking change because it will make upgrades fail etc if they have typos.