argo-cd: apps of apps - dependency (sync-wave) between apps not working
Describe the bug
I am trying to make an app dependent on other apps. Just for sake of an example, I have taken two off the shelf charts - kubernetes-external-secrets and prometheus
NOTE: I have just taken these charts as an example, we have different charts (stored in a git repository) in my organization along with a few kustomized_helm
charts (like kustomize-guestbook) which uses kustomize-helm plugin
To Reproduce I have tried to use sync-waves in vain, it does not look like it is coming into effect at all.
$ kubectl apply -f nonprod-apps.yaml
File nonprod-apps.yaml
for calling other apps
---
apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
name: bootstrap-nonprod-apps
namespace: argocd
finalizers:
- resources-finalizer.argocd.argoproj.io
spec:
project: default
source:
repoURL: <my git repo>
targetRevision: HEAD
path: bootstrap/envs/nonprod
destination:
namespace: default
server: https://kubernetes.default.svc
syncPolicy:
automated:
selfHeal: true
prune: true
App files in the git repository
File 1 prometheus.yaml
---
apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
name: prometheus
namespace: argocd
finalizers:
- resources-finalizer.argocd.argoproj.io
annotations:
argocd.argoproj.io/sync-wave: "-2"
spec:
destination:
namespace: default
server: https://kubernetes.default.svc
project: default
source:
repoURL: https://prometheus-community.github.io/helm-charts
chart: prometheus
targetRevision: 13.3.2
helm:
releaseName: prometheus
version: v3
parameters:
- name: 'alertmanager.enabled'
value: 'false'
syncPolicy:
automated:
selfHeal: true
prune: true
File 2 secrets-manager.yaml
---
apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
name: secrets-manager
namespace: argocd
finalizers:
- resources-finalizer.argocd.argoproj.io
annotations:
argocd.argoproj.io/sync-wave: "-1"
spec:
destination:
namespace: default
server: https://kubernetes.default.svc
project: default
source:
repoURL: https://external-secrets.github.io/kubernetes-external-secrets
chart: kubernetes-external-secrets
targetRevision: 6.2.0
helm:
releaseName: secrets-manager
version: v3
syncPolicy:
automated:
selfHeal: true
prune: true
Expected behavior
I want the status of the prometheus
application to be healthy before argocd moves to secrets-manager
application.
Screenshots
Version
❯ argocd version
argocd: v1.8.5+d0f8edf.dirty
BuildDate: 2021-02-20T11:49:52Z
GitCommit: d0f8edfec804c013d4fc535e8b9022eb47602617
GitTreeState: dirty
GoVersion: go1.15.8
Compiler: gc
Platform: darwin/amd64
argocd-server: v1.8.4+28aea3d
BuildDate: 2021-02-05T17:56:06Z
GitCommit: 28aea3dfdede00443b52cc584814d80e8f896200
GitTreeState: clean
GoVersion: go1.14.12
Compiler: gc
Platform: linux/amd64
Ksonnet Version: v0.13.1
Kustomize Version: v3.8.1 2020-07-16T00:58:46Z
Helm Version: v3.4.1+gc4e7485
Kubectl Version: v1.17.8
Jsonnet Version: v0.17.0
❯
Related Issues / Questions
About this issue
- Original URL
- State: open
- Created 3 years ago
- Reactions: 25
- Comments: 16 (5 by maintainers)
For people hitting this issue, have you enabled health assessment for Argo CD
Application
resources - https://argo-cd.readthedocs.io/en/stable/operator-manual/upgrading/1.7-1.8/#health-assessement-of-argoprojioapplication-crd-has-been-removed ?I seem to have hit the same issue. Argo is not waiting for the helm chart release of App A to become healthy before helm releasing App B.
Hey, any news on that issue? are you guys found some good workaround? I have tried to use neg / positive sync wave values but with no success - its not working on argocd/application on latest version.
It looks I am having the same issue. I’m using ApplicationSet and created the top level application pointing to a set of ApplicationSet from UI, not sure if it introduces any difference. After the top level application created, the apps will be auto-generated after I registered a cluster (I’m using cluster generator), then I see all child applications are created automatically and some applications should have been created after others since I assigned different sync-wave values to them. However, I see they are synced and processing simultaneously. I’ve already added back the custom health check for
Application
resource.@adam-harries unfortunately not, so actually for us this sync-wave feature is not usable, as we constantly evolve our microservice based platform and not install it once only.