Kubernetes CRD schema addition of enum from values.yaml

Question

I'm trying to install a CRD present inside a helm chart.

My openapi schema is working as expected but for one tiny hiccup: I want to add a dynamic enum to the CRD, using the values that I'll pass with helm install

Something like this:

clientns:
   type: string
   enum: [{{ range .Values.rabbitmqjob.default.namespaces | split }}]

when I run the install command as:

helm install . --values values.yaml --generate-name --set "rabbitmqjob.default.namespaces={ns1,ns2}" -n ns1

I get the following error:

Error: INSTALLATION FAILED: failed to install CRD crds/crd.yaml: error parsing : error converting YAML to JSON: yaml: invalid map key: map[interface {}]interface {}{".Values.rabbitmqjob.default.namespaces":interface {}(nil)}

My question is:

1. Is it even possible to do this while installing a crd
2. If yes, then where am I going wrong?

Thanks in advance.

Answer 1

helm install --set has some unusual syntax. In your setup, where you specify

helm install ... --set "rabbitmqjob.default.namespaces={ns1,ns2}"

Helm turns that into the equivalent of YAML

rabbitmqjob:
  default:
    namespaces:
      - ns1
      - ns2

That is, --set key={value,value} makes the value already be a list type, so you don't need string-manipulation functions like split to find its values.

The easiest way to dump this back to YAML is to use the minimally-documented toYaml function:

clientns:
   type: string
   enum:
{{ toYaml .Values.rabbitmqjob.default.namespaces | indent 4 }}

There is a similar toJson that will also be syntactically correct but will fit on a single line

enum: {{ toJson .Values.rabbitmqjob.default.namespaces }}

or if you do want to loop through it by hand, range will return the individual values without specific extra processing.

enum:
{{- range .Values.rabbitmqjob.default.namespaces }}
  - {{ . }}
{{- end }}

If you get odd YAML errors like this, running helm template --debug with the same options will print out the rendered-but-invalid YAML and that can often help you see a problem.

This isn't specific to CRDs. I'd consider it slightly unusual to have configurable elements in a custom resource definition, since this defines the schema for both the controller code that processes custom resource objects and the other services that will install those objects. You'd hit the same syntactic concerns anywhere in your Helm chart, though.