Extend K8up Status resources with Conditions about k8up

[Kidswiss]

Well the first one isn't that bad. As the operator will clean up older jobs anyways. So the amount of CRs with the old status fields should die out rather quickly. For some clusters it's configured to keep no older Jobs at all.

[ccremer]

I would also welcome this. Just adding conditions without removing/changing the existing ones is backwards compatible (e.g. we can just run the operator and after reconcile the existing objects will get the new conditions).
However, if we remove existing status fields from the CRD, would we need to make a new API version? (v1alpha2)
Maybe the K8s deserializer can ignore status fields that aren't expected in the CRD definition

[ccremer]

I took the liberty to refine this feature request

[Kidswiss]

Maybe the K8s deserializer can ignore status fields that aren't expected in the CRD definition

We can test this while implementing this I guess, by simply removing the old status fields, running the operator and see what happens.

[ccremer]

I think it's the other way round: Remove the status fields from the CRD, update CRD, add/keep status fields in the YAML of an object, then run Operator. I expect either:

1. The unknown status fields are left as-is, which would be kinda "bad", as they won't get cleaned
2. The operator removes unknown status fields and only stores the one it knows