Support for CRUD sub resources in the Client

[shawn-hurley]

Currently, I do not see a way to use subresources from the client.

I suggest that we add a variadic argument for subresources. example: https://github.com/kubernetes/client-go/blob/master/dynamic/interface.go#L32

Or we may need to add the subresources to the Options for functions that already have a variadic?

[coderanger]

There is limited support for the status subresource via https://github.com/kubernetes-sigs/controller-runtime/blob/master/pkg/client/client.go#L143

[liyinan926]

I have a similar use case here that needs to evict pods instead of simply deleting them, using the eviction subresource of Pod.

[DirectXMan12]

/kind feature

We had some initial ideas for how to design this, but I think the interface needs potential a bit more work. For instance, should we do client.Subresource("name").Update(obj)? Can we discover name from the object? (maybe?). Thoughts and usecases always welcome :-)

[shawn-hurley]

So your thinking that we have a subresoureces Client, that has an interface containing Create, Update, Delete and Get that look exactly the same as the current interface?

I don't understand how we could determine the subresources for the object, could you explain what you had in mind would love to look into this.

I am assuming that we would want to keep the StatusWriter because it is so common that the helper makes sense?

[DirectXMan12]

Depending on the subresource, we could use a RESTMapper to convert a Kind to the corresponding subresource entry in discovery, IIRC, but I haven't confirmed that -- it's just an initial thought off the top of my head. This doesn't work with subresources like status, though (even though we deal with status separately). I'd be curious to see what seemed more readable or ergonomic.

[fejta-bot]

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle stale

[jay-rob]

Is this issue looking for help? I have a need for doing the client supporting subresources such as get pods/log

[DirectXMan12]

yeah. In general, anything in CR that doesn't have someone working on it is open for help -- I tend to apply the help-wanted tag a bit less in cases where the design might be a bit thorny or that might require serious apimachinery spelunking, but if you're up for some back and forth on design, I'm happy to have someone working on it :-)

[fejta-bot]

Stale issues rot after 30d of inactivity.
Mark the issue as fresh with /remove-lifecycle rotten.
Rotten issues close after an additional 30d of inactivity.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle rotten

[DirectXMan12]

/remove-lifecycle rotten
/lifecycle frozen

[cadedaniel]

+1 to this. Is there a quick way to document that this isn't supported, or return a 5xx when one tries to do so against envtest? Kubebuilder (which uses envtest) suggests users update status via err = r.Status().Update(context.Background(), instance). My controller was failing a new test I wrote because the Update was returning 404, which was really perplexing.

[shawn-hurley]

@cadedaniel I believe that the status subresource should work. If you're getting a 404 return code I would double-check if your CRD has enabled the Status subresource.

[DirectXMan12]

namely, if you're getting 404, make sure that you've done // +kubebuilder:subresource:status on the type definition for your CRD, so you get a CRD with the status subresource enabled.

[cadedaniel]

Yes, I must have missed this. Thanks, ignore my earlier comment please.

[DirectXMan12]

/help

[k8s-ci-robot]

@DirectXMan12:
This request has been marked as needing help from a contributor.

Please ensure the request meets the requirements listed here.

If this request no longer meets these requirements, the label can be removed
by commenting with the /remove-help command.

In response to this:

/help

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.

[fejta-bot]

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

Send feedback to sig-contributor-experience at kubernetes/community.
/lifecycle stale

[zroubalik]

/remove-lifecycle stale.

[fejta-bot]

Stale issues rot after 30d of inactivity.
Mark the issue as fresh with /remove-lifecycle rotten.
Rotten issues close after an additional 30d of inactivity.

If this issue is safe to close now please do so with /close.

Send feedback to sig-contributor-experience at kubernetes/community.
/lifecycle rotten

[zroubalik]

/remove-lifecycle stale

[k8s-triage-robot]

The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs.

This bot triages issues and PRs according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Reopen this issue or PR with /reopen
• Mark this issue or PR as fresh with /remove-lifecycle rotten
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/close

[k8s-ci-robot]

@k8s-triage-robot: Closing this issue.

In response to this:

The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs.

This bot triages issues and PRs according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Reopen this issue or PR with /reopen
• Mark this issue or PR as fresh with /remove-lifecycle rotten
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/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.

[zroubalik]

/reopen

[k8s-ci-robot]

@zroubalik: You can't reopen an issue/PR unless you authored it or you are a collaborator.

In response to this:

/reopen

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.

[zroubalik]

/remove-lifecycle rotten

[alfredkrohmer]

@shawn-hurley can you please re-open this issue?

[k8s-triage-robot]

The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs.

This bot triages issues and PRs according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue or PR as fresh with /remove-lifecycle stale
• Mark this issue or PR as rotten with /lifecycle rotten
• Close this issue or PR with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

[FillZpp]

/remove-lifecycle stale

[idoru]

+1 this would be great to have to also access the serviceaccount/token subresource for controllers that may need to make API calls with arbitrary service accounts.

[k8s-triage-robot]

The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs.

This bot triages issues and PRs according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue or PR as fresh with /remove-lifecycle stale
• Mark this issue or PR as rotten with /lifecycle rotten
• Close this issue or PR with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale