-
Notifications
You must be signed in to change notification settings - Fork 5.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Map helm lifecycle hooks to ArgoCD pre/post/sync hooks #355
Comments
Also need to exclude test hooks: |
It turns out helm hooks are not very widely used, at least not in the public charts. Here are the charts I found using it:
Deprioritizing this. |
The 'crd-install' install hook is getting popular. I guess because this is very convenient way to handle CRDs in helm. We should support this one hook at least.
|
What would be the workaround to this? |
@alexmt not that I know of for now. |
pre-install hooks in combination with hook-weight are very useful, for example in case when we need to create pvc and then do something with persistent volume during installation (but not when we upgrading app). Same could be achieved with init containers and scripting, but it's more complicated, especially when hooks must run in certain order |
This is also important for the influxdb helm chart. It uses a post-install hook to set the admin user for http auth |
The difficulty is that, none of these hooks (pre-upgrade, post-upgrade, pre-install, post-install, pre-delete, post-delete) actually map cleanly to any concepts in Argo CD. Even pre-upgrade does not map cleanly to PreSync, because pre-upgrade is not executed during the initial deploy. In order to support helm hooks properly, we would likely need to introduce granular Application phases/state. All of these imperative executions of hooks are somewhat antithetical to gitops style of deployments where desired state is stored in git, which makes the implementation of this a bit involved. |
Could we document work-arounds? |
Here's where I stand on this, after studying the use of these hooks in public helm charts. For a first pass at this, I think the following mapping might solve 70% of peoples use cases:
It's not a 100% clean/accurate mapping, but based on what we observe in public helm charts, it nearly matches the intent of these chart hooks. Even though the mapping is not clean, the key problem it avoids, is introducing application life-cycle state into Argo CD. |
Why do you have to map then rather than actually implementing them as they were designed? As you have pointed out the mapping isn't clean or accurate and thus isn't really what the ask is. |
I've broken this ticket into 5 smaller tickets to make it easier to deliver incremental value. We can close this one when they are 4/5 are complete. #2038 is for some other time. |
As I mentioned, the only way to support the exact meanings of helm hooks, we would need to introduce lifecycle state into an application. In other words, introduce/maintain a state machine of where the application is in its lifecycle. This state machine could easily become inaccurate (e.g. resources were existing and the argocd app was created to manage those resources after the fact). We are trying to avoid introducing lifecycle state so the middle ground here is to honor a subset of the common concepts between helm/Argo CD. |
I ran into this when trying to deploy the sparkoperator via ArgoCD. The installation of the webhook cleanup job installed as part of the sparkoperator got stuck and complains that it cannot be installed because it is unable to reach a service account that is also created by the helm chart. |
hi guys, the spark operator exposes a few hooks with "helm.sh/hook": pre-delete annotation. I understand this is not supported by ArgoCD => https://argoproj.github.io/argo-cd/user-guide/helm/#helm-hooks, but the one of those hooks runs as a first resource to be created, essentially failing relying on an already How does argo treats those annotation, does it change it to a default 'install' now ? |
@bgvladedivac Unfortunately, ArgoCD uses Helm just as YAML generator ( e.g. |
Just to add to the current situation, this means you cannot deploy airflow using helm with the official helm chart as of today Airflow gets stuck waiting for a postgressDB migration which never occurs because that relies on the hooks |
@pascalwhoop Hi! I found the issue with Airflow helm chart some time ago. Could you please test my solution and may be leave some comments in the PR? |
@pascalwhoop @dnskr for reference, the user-community airflow chart dose not have issues with argo-cd. This is because it uses a Deployment rather than a Job to manage db-migrations (with the option of changing back to a post-install Job using the |
I have the exact same problem, I'm trying to use Argo to deploy the official Airflow Helm chart, and have the same issue where the containers wait forever for the database migration that never happens. Is there any solution? |
I found the solutions in these PRs apache/airflow#16291 and apache/airflow#16331, they work! |
The anchor feature in ksonnet v0.12 is the support of helm registries and chart installations. e.g.:
After we upgrade ArgoCD to use ksonnet v0.12, and do a
ks show
, we will start getting helm hook resources. Since ArgoCD is handling the apply, we will need to build in helm knowledge to skip over hooks during the sync (ksonnet is doing this as well during aks apply
).Additionally helm supports the following hooks:
https://github.com/kubernetes/helm/blob/master/docs/charts_hooks.md
As part of an ArgoCD sync, at the minimum, these resources should be ignored. It can be a feature to map the helm hooks as ArgoCD hooks. (e.g. pre-upgrade and post-upgrade could map to PreSync and PostSync).
The text was updated successfully, but these errors were encountered: