Skip to content
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

feature request: fake client should try to automatically determine objects with subresources #2386

Closed
nicks opened this issue Jun 23, 2023 · 7 comments
Labels
kind/support Categorizes issue or PR as a support question.

Comments

@nicks
Copy link

nicks commented Jun 23, 2023

Background

In v0.15.0, there was a breaking change to the fake client. Now, callers setting up a fake client need to manually call WithStatusSubresource for objects that have a status subresource. For more info, see:

#2259

Feature Request:

Rather than force users to manually configure the fake client, could we use reflection to check if the "Status" field exists? since it's just fake code, this seems like it would be safe?

Alternative implementations:

Alternatively, we could use the ObjectWithStatusSubResource interface from https://github.com/kubernetes-sigs/apiserver-runtime/blob/33c90185692756252ad3e36c5a940167d0de8f41/pkg/builder/resource/types.go#L81, but i'm not sure how widespread that is

@alvaroaleman
Copy link
Member

No, because while enabling the status subresource requires a status field the inverse isn't true, having a status field doesn't mean you have to enable the status subresource. It's simply a setting on the CRD. As a result, it's not possible to automatically detect that.

@nicks
Copy link
Author

nicks commented Jun 26, 2023

re: "it's not possible to automatically detect that" -

yep, that's the feature request. i'm not super opinionated about the implementation. i another way i could think of is to have the kubebuilder:subresource:status tag documented here (https://book-v1.book.kubebuilder.io/basics/status_subresource.html) generate some signals to help with the detection.

@alvaroaleman
Copy link
Member

alvaroaleman commented Jun 26, 2023

yep, that's the feature request. i'm not super opinionated about the implementation. i another way i could think of is to have the kubebuilder:subresource:status tag documented here

That information is not available to the fake client, you need the source code of the CRD for that. "it is not possible" means what it says on the tin. If you just pass in a type we can't infer from it if it has a status subresource or not. You will need to pass in something else. It was discussed that we could infer this from the CRD which would work, but that would still require passing in the CRD. So one way or another, it has to be explicitly configured.

@troy0820
Copy link
Member

Are you still having issues with this @nicks ? Can this be closed?

@troy0820
Copy link
Member

/kind support

@k8s-ci-robot k8s-ci-robot added the kind/support Categorizes issue or PR as a support question. label Sep 25, 2023
@troy0820
Copy link
Member

troy0820 commented Dec 1, 2023

Closing in response to the above answers. If this is still causing problems, please feel free to reopen.
/close

@k8s-ci-robot
Copy link
Contributor

@troy0820: Closing this issue.

In response to this:

Closing in response to the above answers. If this is still causing problems, please feel free to reopen.
/close

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
kind/support Categorizes issue or PR as a support question.
Projects
None yet
Development

No branches or pull requests

4 participants