Move crds directory to the place that helm 3 expects

[restingbull]

A slightly ambigious wording in the helm crd docs can lead one to expect the crds directory to exist inside templates.

One can, however, check to see if helm understands where the crds live by using helm show crds.

Before this pr:

$ helm show crds charts/cloudnative-pg
$

After:

$ helm show crds charts/cloudnative-pg
description: |-
{{- if .Values.crds.create }}
apiVersion: apiextensions.k8s.io/v1
kind: CustomResourceDefinition ...

fixes: #537

[restingbull]

A slightly ambigious wording in the helm crd docs can lead one to expect the crds directory to exist inside templates.

One can, however, check to see if helm understands where the crds live by using helm show crds.

Before this pr:

$ helm show crds charts/cloudnative-pg
$

After:

$ helm show crds charts/cloudnative-pg
description: |-
{{- if .Values.crds.create }}
apiVersion: apiextensions.k8s.io/v1
kind: CustomResourceDefinition ...

fixes: #537

Oh dear. This turns out to be backwards incompatible change:

• helm 3 doesn't template crds.
• crds.create = true is no longer viable, so removed.

I can understand if this is the wrong time to make this update.

[phisco]

helm doesn't handle in-place CRD updates, we have to keep it in the templates folder otherwise it'll fail on upgrades as soon as we add a field or change anything in the CRD. That's a known limitation of helm.

[restingbull]

helm doesn't handle in-place CRD updates, we have to keep it in the templates folder otherwise it'll fail on upgrades as soon as we add a field or change anything in the CRD. That's a known limitation of helm.

Hm. Helm is being unhelpful here -- keeping the crds in templates forces method 2, over method 1.

Unpleasant packaging issue.

With that in mind, why keep the CRDs in the same chart as the operator?

[itay-grudev]

@restingbull How do you propose distributing them otherwise? This approach allows us to make sure you have the appropriate CRD versions when updating the operator. If you need to manage them in some other way depending on your environment you can always set the crds.create=false flag.

[restingbull]

@restingbull How do you propose distributing them otherwise? This approach allows us to make sure you have the appropriate CRD versions when updating the operator. If you need to manage them in some other way depending on your environment you can always set the crds.create=false flag.

More layers, if a toy example is correct. Mind you, helm doesn't document the dependency ordering so this idea may be doomed from the start -- but as of v3.17.1, the dependencies are listed first during a template.

So, the hypothetical solution is:

• Extract the CRDs to a separate chart
• Add the chart as a dependency on the operator chart.

I'll try this out and open a PR if it works.

[itay-grudev]

Even with a subchart you still have the limitation that Helm doesn't upgrade CRDs.