-
Notifications
You must be signed in to change notification settings - Fork 1.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Create and Add HasStatus
interface on Objects which Actually have Status
#3586
Comments
Relates to #3474 (comment) |
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 |
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. |
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. |
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! |
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. |
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 toHasMetadata
to differentiate between those resource. So all the k8s objects would implementHasStatus
(with a getter and setter), that use status sub-resource. Other don't.This would help to implement this issue in Java Operator SDK: operator-framework/java-operator-sdk#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.
The text was updated successfully, but these errors were encountered: