CRD breaks install

[stobias123]

Error: rendered manifests contain a resource that already exists. Unable to continue with install: existing resource conflict: kind: CustomResourceDefinition, namespace: , name: kongconsumers.configuration.konghq.com

[vietwow]

I got the same issue and posted in here : Kong/kong#5520

[hbagdi]

Can you try the following?

helm install kong/kong --set ingressController.installCRDs=false

We have to keep compatibility with Helm v2 and hence the above flag is necessary if you CRDs already exist in the cluster.

[vietwow]

It works now, thank you so much.

[hbagdi]

This happens because of 0a73684. @yspotts Seems like we need to specify --skip-crds and --set ingressController.installCRDs=false to solve this issue in Helm 3.

[hbagdi]

This problem is actually worse.
Even for a fresh installation of Kong using Helm 3, you need to do
helm install kong/kong --set ingressController.installCRDs=false because Helm 3 will install the CRDs in the crds directory first, meaning, Helm 3 will try to install CRDs twice.

[yspotts]

@hbagdi hmm. that is unfortunate. I wonder how other projects handle this. I can do some research. In the meantime, do we want to update the docs to make it clear for helm 3, you must set that value to false?

[hbagdi]

We should. PR welcome!

[yspotts]

will do!

So I believe the reason this is not an issue in other projects is that they use the crd-install hook for their CRDs. This hook was removed for Helm3, so I am guessing the CRD will never get installed for helm3 since that hook will never run. Not sure we want to add that hook at this point...

[yspotts]

@hbagdi PR opened.

[lindhe]

This problem is actually worse.
Even for a fresh installation of Kong using Helm 3, you need to do
helm install kong/kong --set ingressController.installCRDs=false because Helm 3 will install the CRDs in the crds directory first, meaning, Helm 3 will try to install CRDs twice.

Just to clarify for anyone passing by: That's not a valid helm install command in Helm 3, since it's required to specify a release name. Either add the flag --generate-name or give it a name like so: helm install mykong kong/kong --set ingressController.installCRDs=false where mykong is the name of your release.

[lindhe]

It seems to me that the issue is that the template file should not try to install the crd's when using Helm 3, since Helm 3 will do that already.

[lindhe]

I've asked in the helm-users slack channel, and nobody replied saying that there's an easy way to detect in a template if we're running Helm 2 or Helm 3. So I guess we'll need another approach here. Not yet sure what that is. The naïve way is to just have a flag like --helm3support enabled but it's pretty ugly.

I think that all of this stems from having a crds catalog but still supporting Helm 2. Could we drop Helm 2 support?

[hbagdi]

Docs are missing for installation for Helm3. #34

As much as I wish to drop support for Helm 2, I don't think it is reasonable at this point given that Helm 3 came out relatively recently and most users are still on Helm 2.
On the contrary, I'd consider dropping support for Helm 3 until there is some tooling (from the Helm community) to manage charts for both versions of Helm.

[lindhe]

As much as I wish to drop support for Helm 3

I guess you mean Helm 2

On the contrary, I'd consider dropping support for Helm 3 until there is some tooling (from the Helm community) to manage charts for both versions of Helm.

Helm 3 have done a fairly good job of making it backwards compatible. A valid Helm 2 chart (i.e. with apiVersion: v1) should be installable with Helm 3. I guess we've found an edge case here, but was there a problem before the introduction of the crds directory?

[hbagdi]

I correct my comment about. Sorry for the typo.

I guess we've found an edge case here, but was there a problem before the introduction of the crds directory?

Probably not. That's the only change we introduced to work towards Helm 3 compatibility.

The more I think about it, the more I feel that we should revert the crds directory change.

@rainest Thoughts?

[yspotts]

that would be really unfortunate. It would certainly break our workflow and require two separate stages for helm install.

As I mentioned above - I believe the other projects provide helm 3 support without breaking helm 2 by using a crd-install hook which is only for helm 2. Best I can tell, it would be ignored by helm 3.

Barring that, do you believe docs for helm 3 (in my PR) would be insufficient for providing support for helm 3 for those that want it?

[lindhe]

One strategy that would for sure work is to have one file in crds/ and a template file with the crd-install hook annotation in the templates/ directory. The template file will never be installed by Helm 3 since Helm 3 ignores the crd-install hook, and the files in crds/ will never be installed by Helm 2 since it does not look there. (see https://kubernetes.slack.com/archives/C0NH30761/p1581373188073800)

But that leads to repeated code, which is pretty unfavorable.

[hbagdi]

Alright, I believed that we had a reason for not using the crd-install hook but doing some git spelunking, I couldn't find any reason.

It is worth a try to solve this problem by introducing the crd-install hook and as folks here suggest, it will solve the problem for Helm 2 and Helm 3.

Can someone in this thread open a quick PR to add those hook annotation to the chart?

[yspotts]

I hope to be able to get to it in the next few days...

[yspotts]

@hbagdi #49

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.