StephanSalas
commented
2 years ago If there's any quick workaround, please let me know as well. If not, I think this would be a great addition to the ArgoProj because it supports the wider community's future architecture and goals toward custom-resource use.
Also would this be a good place to start looking to incorporate a solution?: https://github.com/argoproj/argo-cd/blob/2da0e81b057e861cce954c44c715b2d64d4bed9a/controller/health.go
Summary
Currently child Kubernetes CRs of parent Kubernetes CRs do not have existing Argo-Healthchecks applied to their types when created by an Argo Application CR.
This is inconsistent with native-kubernetes containerized deployments, which use the logic defined https://github.com/argoproj/argo-cd/blob/83458e0bd965132454d6e7d6569d106821fe8add/ui/src/app/applications/components/utils.tsx#L756 in order to accomplish this via deployments, replicasets, and pods.
I am proposing extending this support to Kubernetes CRs that are children of other CRs that are created by an Argo Application.
Motivation
Custom operators are the perfect use-case for this, because deploying one resource might trigger the deployment of many child resources. If you want to consider the whole application and its dependents as "healthy" or "degraded", adding support for Healthchecks on Child Custom Resources is the best way.
Proposal
Extend healthcheck logic to child CRs (today top-level parent CRs are the only CRs that Argo-Healthchecks apply to) such that the UI reports on their progress given that there exists a custom healthcheck type in the argo-cm configmap.