Helm-operator: Helm3 operator seems to ignore helm chart hooks

Created on 10 Jan 2020  Â·  6Comments  Â·  Source: fluxcd/helm-operator

Description
Helm3 operator seems to ignore helm chart hooks.

The setup

  • minikube 1.3.1 with k8s 1.15.2
  • flux version 1.17.1
  • Helm operator version 1.0.0-rc6 with configuration
    helm: versions: v3
  • A helm chart with deployment, service, ingress
  • A job hook with
    metadata: annotations: "helm.sh/hook": post-install "helm.sh/hook-weight": "1"
    Expected behavior
    I expect the Helm operator to deploy the Job hook.

In my case the job should start a Pod, which creates a database and a database
user. But no job is started.

All the other helm chart objects (deployment, service, ingress...) are deployed
as expected.

Replacing the job hook by the Helm documentation's hook example won't work
either.

If I use helm CLI either from the host system or helm3 from within the
helm-operator container to deploy the helm chart, the job hook is executed.

Since in Helm operator 1.0.0-rc5 release notes it is said that

We also no longer shell out to the helm binary to achieve certain
functionalities but instead make directly use of the available Helm packages

Thus, I assume that there is an issue with the helm-operator. Please let me know, if you run into the same problem. Maybe I missed something.

blocked needs validation bug helm v3

Most helpful comment

@joachimmathes no worries, glad you figured it out on your end, _and_ that it wasn't due to the operator.

Do not hesitate to report issues like this again, as long as they are well composed it is fairly easy to triage them without being too time consuming, and it's better to be safe than sorry. :tulip:

All 6 comments

Based on the comment here https://github.com/fluxcd/helm-operator/issues/8#issuecomment-573216729, and the fact that we do not disable hooks (this is never set). I would expect them to be executed.

Can you provide me a chart in stable the issue exists for?

Ok, did some research. Good news: Everything is fine with the helm-operator.

The problem was a deadlock in our setup. The hook prepares a resource, which is needed by a pod, that the hook is waiting for becoming ready. In our case this could be fixed by replacing post-install with pre-install.

Nevertheless, we are pretty sure that things worked with helm 2 and tiller. We guess that the --wait-issue in https://github.com/helm/helm/issues/3173 was the reason.

Sorry, for the false alarm.

@joachimmathes no worries, glad you figured it out on your end, _and_ that it wasn't due to the operator.

Do not hesitate to report issues like this again, as long as they are well composed it is fairly easy to triage them without being too time consuming, and it's better to be safe than sorry. :tulip:

Having the opposite problem. The hook runs, but it doesn't actually wait until pods are ready (which is important for the hook)...

running the chart into the cluster via the helm cli command works fine. flux/helm-operator doesn't look like it's sending the --wait properly.

Try setting spec.wait to true, this will make the operator behave like
the flag is set.

On Fri, 21 Feb 2020 at 01:33, Ryan Gahl notifications@github.com wrote:

Having the opposite problem. The hook runs, but it doesn't actually wait
until pods are ready (which is important for the hook)...

running the chart into the cluster via the helm cli command works fine.
flux/helm-operator doesn't look like it's sending the --wait properly.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/fluxcd/helm-operator/issues/195?email_source=notifications&email_token=ACMYZP6DXM3PLDRWAOHT7ZDRD4OPFA5CNFSM4KFFRIUKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEMRCQFY#issuecomment-589441047,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ACMYZPYSRA7FSIZ3K4GZFFLRD4OPFANCNFSM4KFFRIUA
.

Oh jeez. Another day done, and another day I feel dumb for not finding the right documentation :)

Thank you @hiddeco

Was this page helpful?
0 / 5 - 0 ratings