9

I have a helm chart A which depends on a third-party subchart B. Chart B defines some CRDs which are used by chart A. However, when I install chart A (hence B too), I get an error saying that the CRDs are not recognized. It seems that the CRs are being stored before CRDs.

Helm documentation about CRD describes two ways to handle this order, either put the CRDs in a folder called crds, or use two separate charts and install them one after the other.

My questions are the following:

  1. Why doesn't Helm apply first the CRDs regardless of where they are? Why is the crds folder needed? What if the CRDs are in a chart that you don't wish to modify (like in my case)?
  2. Doesn't the second option make the dependencies specification useless. Can't there be an order of execution for dependencies?
  3. Is there a way, that I might have overlooked, to still keep 1 chart with a dependency and somehow make sure that the CRDs defined in the dependency are stored before being used? (hooks?)

(you don't have to answer all the questions, an answer to any of them is appreciated)

gtato
  • 400
  • 2
  • 11

2 Answers2

4

There's a pretty simple way to let your main chart install the objects defined by your dependency chart's CRDs. Just make them installed and upgraded with the post-install and post-upgrade hooks.

Just a simple example for you. Let's imagine, you need to install a cert-manager as a subchart and then your main chart needs to install an Issuer. Obviously, the initial installation fails, as the CRDs aren't installed yet, so the Issuer doesn't pass validation. But if you use the hook (by adding the following annotation to the template of your Issuer: "helm.sh/hook": post-install,post-upgrade), then the Issuer will be installed only in the very end of the installation procedure, when cert-manager is up and kicking.

Volodymyr Melnyk
  • 383
  • 3
  • 13
1

Full reasoning on how Helm handles CRDs can be found in hip-0011. I recommend reading it, but in short:

1. "The core problem is that CRDs (being a globally shared resource) are fragile. Once a CRD is installed, we typically have to assume that it is shared across namespaces and groups of users. For that reason, installing, modifying, and deleting CRDs is a process that has ramifications for all users and systems of that cluster."

and

"This was an explicit decision after much community discussion due to the danger for unintentional data loss"

  1. No, dependencies can and are used for other purposes too.

  2. I'm afraid it will be complicated, check the discussion here.

hess
  • 76
  • 5