Skip to content
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

Closed
rdelpret opened this issue Jun 16, 2020 · 13 comments
Closed
Assignees
Labels
bug Something isn't working
Milestone

Comments

@rdelpret
Copy link

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

@rdelpret rdelpret added the bug Something isn't working label Jun 16, 2020
@rdelpret
Copy link
Author

rdelpret commented Jun 16, 2020

@sfynx
Copy link
Contributor

sfynx commented Jun 20, 2020

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 ;)

@rdelpret
Copy link
Author

Yeah, the discussion in slack leaned towards this being the default because it is the most common use.

@alexmt alexmt added this to the v1.8 milestone Sep 22, 2020
@keithchong
Copy link
Contributor

Hi @alexmt, please assign this to me

@raelga
Copy link
Contributor

raelga commented Sep 28, 2020

+1

@keithchong
Copy link
Contributor

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:

3781-before

After (Desired behavior):

3781-after

@keithchong
Copy link
Contributor

keithchong commented Sep 29, 2020

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 (settings/projects/<projectName>) or somewhere else? IMHO, I think anything elaborate like this should be considered an enhancement, and not a bug.

@keithchong
Copy link
Contributor

This is how the child applications will appear now with the changes. There is no health status. You must open the child app to see it's health state.

StatusRemoved

@keithchong
Copy link
Contributor

keithchong commented Oct 6, 2020

Hi @alexmt , can this issue be set to verify?

jon-walton pushed a commit to playstudios/argo-cd that referenced this issue Oct 28, 2020
@alexmt alexmt closed this as completed Oct 29, 2020
@sfynx
Copy link
Contributor

sfynx commented Dec 3, 2020

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...

@trown
Copy link

trown commented Dec 4, 2020

@sfynx https://argoproj.github.io/argo-cd/operator-manual/upgrading/1.7-1.8/#health-assessement-of-argoprojioapplication-crd-has-been-removed worked for me.

@sjentzsch
Copy link

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

@bukowa
Copy link
Contributor

bukowa commented Sep 30, 2022

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.mp4

Solution in case of terraform:

  wait {
    fields = {
      "status.health.status" = "Healthy"
      "status.resources[0].health.status" = "Healthy"
      "status.resources[1].health.status" = "Healthy"
    }
  }

darkdoc added a commit to darkdoc/clustergroup-chart that referenced this issue Nov 4, 2024
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.
darkdoc added a commit to darkdoc/patterns-operator that referenced this issue Nov 4, 2024
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.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

8 participants