Create and Add `HasStatus` interface on Objects which Actually have Status

[csviri]

Some of the standard Kuberentes objects like ConfigMaps don't use status sub-resource, others like (Deployments, Pods, ...) do.

It would be very useful to have a HasStatus interface similar to HasMetadata to differentiate between those resource. So all the k8s objects would implement HasStatus (with a getter and setter), that use status sub-resource. Other don't.

This would help to implement this issue in Java Operator SDK: https://github.com/java-operator-sdk/java-operator-sdk/issues/667

It might be an ide to also support this in the CustomResource abstraction, currently all custom resource POJO has status, although in k8s this is not necessarily true. CRD can define a custom resource without status subresource.

[manusa]

Relates to https://github.com/fabric8io/kubernetes-client/issues/3474#issuecomment-957940971

[metacosm]

It might be an ide to also support this in the CustomResource abstraction, currently all custom resource POJO has status, although in k8s this is not necessarily true. CRD can define a custom resource without status subresource.

While this is definitely true, it should be noted that this isn't recommended and I'd argue that the default behavior should be for Custom Resources to have a status. I'm not sure there's a need to implement something that currently doesn't exist, that users haven't asked for (so far) and that goes against recommendations/good practices.

We should also strive to make the HasStatus backward compatible with CustomResource so that CustomResource could implement the HasStatus interface without breaking existing code, if possible.

[manusa]

It might be an ide to also support this in the CustomResource abstraction, [...]

While this is definitely true, [...]

This is a discussion that also came up in the scope of CRs having a mandatory Spec field. Just like with status, this is not a hard requirement (although it's recommended). I think the agreement was that we want to prescribe the good practice (which is include the default structure ---> spec + status fields) to whomever was using our CR abstractions.

[csviri]

While this is definitely true, it should be noted that this isn't recommended and I'd argue that the default behavior should be for Custom Resources to have a status. I'm not sure there's a need to implement something that currently doesn't exist, that users haven't asked for (so far) and that goes against recommendations/good practices

This is a discussion that also came up in the scope of CRs having a mandatory Spec field. Just like with status, this is not a hard requirement (although it's recommended). I think the agreement was that we want to prescribe the good practice (which is include the default structure ---> spec + status fields) to whomever was using our CR abstractions.

Agree, I don't have strong opinion on this, just was an idea. Basically status is always there in some form (even if its Void), while with this change we want to differentiate resources which has status or not with an interface. But agree that on custom resources usually you want to have it, it's a good practice, also we want to be backwards compatible.

[csviri]

From Java Operator SDK perspective this issues can be closed. For now only the automated observed generation aware functionality would require this. However, it does not makes that much sense for well known Kubernetes resources since the status is already handled by the original controller.

[stale[bot]]

This issue has been automatically marked as stale because it has not had any activity since 90 days. It will be closed if no further activity occurs within 7 days. Thank you for your contributions!

[metacosm]

I would like to reopen this as we're still seeing issues where such a functionality would be useful, in particular, for example when doing RBAC generation, being able to detect whether a status sub-resource exists is needed to provide access to it.