`KuberhealthyCheck` `status` field instead of separate `KuberhealthyState` object

[LS80]

Describe the feature you would like and why you want it

Currently the status of a KuberhealthyCheck is stored in a separate KuberhealthyState object of the same name. Is there a good reason why this isn't instead stored in a status field of the KuberhealthyCheck itself, as is customary in Kubernetes?

Additional context

The separate object makes it impossible to create a custom Argo CD health check for the KuberhealthyCheck, which would allow Argo CD to show the application as unhealthy if a check is failing.

[Hungrylion2019]

LGTM. But the code heavily depend on the khstate. I usually see the khstate or the api "healthCheckHandler" to get current concrete check results.

[fungaren]

See: https://github.com/kuberhealthy/kuberhealthy/issues/1061#issuecomment-1127019154

[sedflix]

I feel that following the kstatus spec would also be helpful for flux health check.

For custom resource definitions (CRDs), there currently isn't much guidance on which properties should be exposed in the status object and which conditions should be used. As part of this effort we want to define a set of standard conditions that the library will understand and that we encourage developers to adopt in their CRDs. These standard conditions will be focused on providing the necessary information for understanding status of the reconcile after apply and it is not expected that these will necessarily be the only conditions exposed in a custom resource

It seems like a good thing to follow as per the motivation of the spec.

[github-actions[bot]]

This issue is stale because it has been open 30 days with no activity. Remove stale label or comment on the issue or this will be closed in 15 days.

[integrii]

I think there are a few reasons we are considering revising the khcheck resource, and using the status section for khstate sounds like a good idea. When we first implemented Kuberhealthy, CRDs didn't usually have a status field!

If we do a CRD refactor, it seems prudent to think about getting rid of the khstate resource...