-
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
Child applications should not effect parent application's health by default #3781
Comments
Relevant slack convo: https://argoproj.slack.com/archives/CASHNF6MS/p1585143412031500 |
I guess a case can be made for both. I have app-of-apps where independent apps are installed and I don't really care about the overall health, but I also have apps that consist of multiple component apps which must all be there for the entire thing to work (essentially being one system semantically), so in that case I'm interested in its overall health. Just like when an app is degraded when some resource in it is also degraded. Whichever scenario is most used should be the default I guess, which is fine to me as long as I can configure otherwise ;) |
Yeah, the discussion in slack leaned towards this being the default because it is the most common use. |
Hi @alexmt, please assign this to me |
+1 |
Is that slack link correct? I'm seeing a thread that talks about issue 2924 Note, currently, if the child's health state is missing or unknown, it will not affect the parent's health state. So, if the child app's health state is "degraded", then the parent app should still be healthy. Before: After (Desired behavior): |
Hi @alexmt , could you comment on this bug, whether there should be a setting of some sort to make the behaviour configurable, perhaps a preference setting from the Projects summary settings page ( |
Signed-off-by: Keith Chong <[email protected]>
Signed-off-by: Keith Chong <[email protected]>
Hi @alexmt , can this issue be set to verify? |
…goproj#4489) Signed-off-by: Keith Chong <[email protected]>
What is the recommended way to configure the old behavior now, where you have a composite app whose parent should only be healthy when all children are healthy (just like it works with non-Application resources inside an Application)? I'm not sure it is really wise to override any built-in health check for the Application CR itself... |
As a note: Configuration to customize resource behavior should now be configured via splitted sub keys, so the proper link to set up the health assessement should be found here now: https://argo-cd.readthedocs.io/en/stable/operator-manual/health/#argocd-app |
I found only one problem with that approach - when the app is created its status is "Healthy" right away. Imagine scenario where your script waits for the app to become healthy, for ex with terraform: resource "kubernetes_manifest" "app" {
wait {
fields = {
"status.health.status" = "Healthy"
}
}
} 0957d238ebea372e11d4508b98c1a7b8.mp4Solution in case of terraform: wait {
fields = {
"status.health.status" = "Healthy"
"status.resources[0].health.status" = "Healthy"
"status.resources[1].health.status" = "Healthy"
}
} |
This was removed in argocd 1.8 see argoproj/argo-cd#3781 To make application ordering, and dependencies possible, this is needed for the app of apps pattern.
This was removed in argocd 1.8 see argoproj/argo-cd#3781 To make application ordering, and dependencies possible, this is needed for the app of apps pattern.
Describe the bug
Currently, when you have an application of applications (parent, children) if the child application is unhealthy the parent application becomes unhealthy. There is currently a workaround to use a resource customization to do this but after discussing with Alex on slack he asked me to file a bug report to make this the default.
To Reproduce
Create an application that manages applications, take some action that forces a child application to an unhealthy state. The parent application will become unhealthy.
Expected behavior
I would like the parent application to remain healthy. it seems redundant for most peoples use cases to bubble up child application health to the parent.
Version
1.5.2
The text was updated successfully, but these errors were encountered: