helmfile apply does not install crds folder
When using apply to install a helm 3 style chart with crds folder we get an error that the kind does not yet exist. Directly installing with sync does work however.
Shouldn't helmfile get a list of installed releases so it knows to use sync upon first install?
Morriz
All 19 comments
There was a discussion related to this: https://github.com/roboll/helmfile/issues/1124
andrewnazarov
on 13 Jul 2020
I saw it yes. I thought it would be beneficial to create a separate issue to isolate the behavior, propose a solution and track progress.
Morriz
on 13 Jul 2020
As a matter of fact I think the refactor from helm 2 to 3 was missing idempotency as a development goal. Most state oriented tools nowadays don't differentiate between initial install / subsequent update because it violates the idempotency principle. It does make sense to hook into both events to create side effects, but the resulting state without those side effects should always reflect the described state imo.
Morriz
on 13 Jul 2020
@Morriz This comes from the fundamental issue on how K8s validates resources. As a workaround, I've added disableValidation: true which should be set for charts like prometheus-operator that tries to install CRDs and CRs on first install. See #1373
Re: idempotency, Helm 3 does support idempotency. You can verify that by e.g. seeing helmfile sync and helm upgrade --install just work against a chart like promethues-operator. It's Helmfile + helm-diff's problem. disableValidation: true is one of the solutions to it.
Another, potential solution would be to enable Helmfile to prevent showing diff on first install as you've suggested. But it shall be a breaking change. I think this specific issue can be addressed by disableValidation so shall we defer the first-install handling to another issue?
mumoshu
on 23 Jul 2020
Thanks. And yes, sure, let's create a separate issue for that then.
And can we provide that flag per release? I don't wish to force sync on all of our releases.
Morriz
on 23 Jul 2020
Also, only the output would be different, but the resulting state is the same, so no breaking change imo. Who would use the text output of apply as input for anything? It's just feedback for humans
Morriz
on 23 Jul 2020
@Morriz Yeah you can set disableValidation per release.
mumoshu
on 1 Aug 2020
Who would use the text output of apply as input for anything?
@Morriz Me :) I'm using it as a casual historical record of what has been installed by apply.
mumoshu
on 1 Aug 2020
Really? Lol.
On Sat, 1 Aug 2020 at 03:31, KUOKA Yusuke notifications@github.com wrote:
Who would use the text output of apply as input for anything?
@Morriz https://github.com/Morriz Me :) I'm using it as a casual
historical record of what has been installed by apply.—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/roboll/helmfile/issues/1353#issuecomment-667447287,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAHF6KKA4BD2YLAQVD2YLV3R6NWAFANCNFSM4OYWSGDA
.
Morriz
on 1 Aug 2020
I am re-reading this again, and am concerned this will happen again soon: CRDs don't get deployed, even though helm 3 supports deploying both CRDs and CRs at the same time.
we would like to be able to add repeatable, indempotent instructions to apply a chart to a cluster, so I would like to ask if helmfile might have solved this problem already in the mean time?
@mumoshu thanks again for your help!
Morriz
on 12 Nov 2020
@Morriz Perhaps we can just enhance Helmfile to automatically set --disable-openapi-validation to helm-diff only when the target release is not yet installed? So that helm-diff called by helmfile would never fail due to missing CRD on first install.
mumoshu
on 13 Nov 2020
Using helm 3.4 and latest helmfile 0.134.1 and still having this very problems while installing charts with CRDs for the first time into an empty EKS 1.18 cluster.
Mainly affects cert-manager and aws-load-balancer-controller.
reixd
on 13 Nov 2020
Thanks!
The current workaround is to install the stack with helmfile sync for the first time, to skip diffing at all.
After that you can add disableValidation: true to your releases depending on the usecase, to get subsequent helmfile apply and helmfile diff to work when you are creating new CRD and CR in one sync. Or you can just avoid adding CRDs and CRs in one shot. That is, add CRDs in the first helmfile-apply, and then CRs in the second apply.
mumoshu
on 13 Nov 2020
Yeah, it works, however this also breaks a workflow where you perform some checks before apply: lint, template validate, diff and apply
reixd
on 13 Nov 2020
@reixd I hear you. Do you think https://github.com/roboll/helmfile/issues/1353#issuecomment-726533131 would resolve your issue?
mumoshu
on 13 Nov 2020
Basically, it's a bit more elegant version of if helm list | grep your-crds-release; then helmfile apply; else helmfile sync.
mumoshu
on 13 Nov 2020
Basically, it's a bit more elegant version
Yeah, I think a patch with this logic would help. If released will give a try today ;)
reixd
on 13 Nov 2020
But how is that automated? How can a stateless script detect that a first install is needed?
On 13 Nov 2020, at 07:21, Rei notifications@github.com wrote:

Yeah, it works, however this also breaks a workflow where you perform some checks before apply: lint, template validate, diff and apply—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or unsubscribe.
Morriz
on 13 Nov 2020
That really depends on your setup. If you have only single release for all the CRDs, the workaround works. If the list of releases that contains CRDs changes dynamically, the only way would be script something better on your own, or wait for https://github.com/roboll/helmfile/issues/1353#issuecomment-726548807
mumoshu
on 13 Nov 2020
Related issues
aslafy-z
·
4Comments
daaain
·
3Comments
mumoshu
·
4Comments
mumoshu
·
4Comments
cilerler
·
3Comments
Most helpful comment
Basically, it's a bit more elegant version of
if helm list | grep your-crds-release; then helmfile apply; else helmfile sync.