Support for CRUD sub resources in the Client about controller-runtime

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

[zroubalik]

Status is working, are there any plans to include Scale subresource as well? I'd like to control it from the client the same way it could be done via client-go.

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

[zroubalik]

/remove-lifecycle stale.

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

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

[vincepri]

/kind design

[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

[timebertt]

/remove-lifecycle stale
Any updates on this?
If there is a plan for how this should be implemented or we can agree on a design, I might be able to help with the implementation :)

[vincepri]

@tim-ebert We're waiting for a design proposal, see under designs/ for a template and examples

[alexeldeib]

heads up for anyone deciding to tackle this, versioning gets weird with scale: https://github.com/kubernetes/client-go/blob/36233866f1c7c0ad3bdac1fc466cb5de3746cfa2/scale/client.go#L182-L201

[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

[timebertt]

/remove-lifecycle stale

[alvaroaleman]

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

Those are not CRUD subresources, see #452 for that

@DirectXMan12 What is the concern with adding a simple ForSubresource(name string) Create/Patch option for this? Seems pretty straightforward and doesn't require any external API changes I think. It obviously allows for misuse if ppl use it for non-existing subresources but I think that should be ok if we add a warning to it?

[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]

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

[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

[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