Open isugimpy opened 6 months ago
Loosely related to this, would Flux maintainers be open to adding more known objects to kstatus beyond simply core and generic?
Loosely related to this, would Flux maintainers be open to adding more known objects to kstatus beyond simply core and generic?
There is an rfc in the work that will address this: https://github.com/fluxcd/flux2/pull/4528
Describe the bug
When attempting to reconcile resources with
status.observedGeneration
using type string instead of int64, health checking fails due to not being able to parse the field. An example of this is observed in https://github.com/fluxcd/flux2/discussions/1476 as well as mentioned on the Istio repo. Currently, I'm experiencing this when attempting to use Argo Rollouts with Flux.Steps to reproduce
spec.wait: true
, containing a rollouts.argoproj.io/v1alpha1Expected behavior
Flux should find that the field exists and attempt to convert the string to an int64, only failing if it cannot be parsed as an integer.
Screenshots and recordings
OS / Distro
N/A
Flux version
N/A
Flux check
Git provider
N/A
Container Registry provider
N/A
Additional context
I've tested this on 2.0.1 and 2.2.3, observing the same behavior (though, as I recall, 2.0.1 may not be using kstatus). This appears to be a simple patch in https://github.com/fluxcd/cli-utils/blob/5af6753e42af4622cd7d6e16ffe1fb2f946a2103/pkg/kstatus/status/generic.go#L73-L99, which I've written up and tested locally, and am willing to submit if it'd be accepted.
Code of Conduct