Kubernetes CRD schema addition of enum from values.yaml - kubernetes

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:
Is it even possible to do this while installing a crd
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.