-
Notifications
You must be signed in to change notification settings - Fork 1.1k
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
✨ Support subresource modification #1922
Conversation
|
Welcome @g7r! |
Hi @g7r. Thanks for your PR. I'm waiting for a kubernetes-sigs member to verify that this patch is reasonable to test. If it is, they should reply with Once the patch is verified, the new status will be reflected by the I understand the commands that are listed here. 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. |
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: g7r The full list of commands accepted by this bot can be found here.
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
/ok-to-test |
/cc @FillZpp |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I actually ran into this exact problem recently and was scratching my head about why it wasn't working. Thanks for submitting this!
This seems to be the solution for #172
My only small concern with this is that it might imply it handles more than CRUD (e.g. pods/logs
or an arbitrary subresource of an APIService. Perhaps GoDoc is enough to document the limitations?
pkg/client/client.go
Outdated
func (c *client) Status() StatusWriter { | ||
return &statusWriter{client: c} | ||
func (c *client) Status() SubResourceWriter { | ||
return &subResourceWriter{client: c, subResource: "status"} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Does this work?
return &subResourceWriter{client: c, subResource: "status"} | |
return SubResource("status") |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Absolutely! Thanks for the suggestion. I've applied it here and to other similar places as well.
type StatusWriter interface { | ||
// SubResourceClient knows how to create a client which can update subresource | ||
// for kubernetes objects. | ||
type SubResourceClient interface { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
One thing I am wondering is if this should maybe be called something like SubResourceCRUDClient
or some such to clarify that this can not deal with other subresources like logs and differentiate it from a potential future non-crud subresource client?
I am not sure though if it is possible to come up with a sensible non-crud subresource client, since that could basically be anything? Maybe that one would just be a standard http client? Ref #452
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thinking about it it again, maybe we should instead just add more verb(s) once we get there?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Some comments to this CRUD subresource client. It's nice that we can read/write more subresources in controller-runtime.
Also a non-CRUD subresource client will be great, but it is not easy to define a common interface for those subresources. It seems they are all defined for K8s built-in resources and don't support custom resources (I'm not sure). So maybe document that those could only be handled via client-go temporarily? WDYT @alvaroaleman @joelanford
type StatusWriter = SubResourceWriter | ||
|
||
// SubResourceWriter knows how to update subresource of a Kubernetes object. | ||
type SubResourceWriter interface { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We may also have to define a SubResourceReader
. Sometimes ppl want to get some subresources, for example getting a Scale
subresource allows us to get the expected and current replicas number of any workloads (e.g., Deployment, StatefulSet), like what podautoscaler controller and disruption controller do.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We could probably in the future replace the currrent SubResourceWriter interface with a SubResourceClient and then add read functionality in there?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Or we could have both SubResourceReader and SubResourceWriter, like the Reader and Writer?
And also the SubResourceWriter needs more methods other than Update and Patch, for example the subresource pods/binding has to be POST, which is actually Create.
// UpdateStatus used by StatusWriter to write status. | ||
func (c *typedClient) UpdateStatus(ctx context.Context, obj Object, opts ...UpdateOption) error { | ||
// UpdateSubResource used by SubResourceWriter to write status. | ||
func (c *typedClient) UpdateSubResource(ctx context.Context, obj Object, subResource string, opts ...UpdateOption) error { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
IMHO, one obj Object
in the parameters is not enough, because not all subresources (even CRUD subresources) take the original object as its request body. For subresources like Status
and Finalize
, yes. For subresources like Scale
, no, which actually accept a autoscaling.Scale
as the request body.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, we definitely need that, apart from Scale there is also authenticationv1.TokenRequest
in the case of serviceaccount tokens...Maybe we can have a StatusUpdateOption
that has a Body Object
field on top of the other UpdateOptions
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
SGTM, or we can have two objects in the UpdateSubResource parameters like
(ctx context.Context, obj Object, subObj Object, subResource string, opts ...UpdateOption)
If the subObj
is not nil, we should take it as the update body, otherwise we will use the obj
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Due to the fact that it is not always mandatory I'd prefer to make it part of the opts and we can then provide a convenient wrapper, so that you can do something like:
c.UpdateSubresource(ctx, myObj, "my-subresource", client.WithSubResourceBody(mySubResource))
@g7r do you have the cycles to address the feedback on this? |
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:
You can:
Please send feedback to sig-contributor-experience at kubernetes/community. /lifecycle stale |
I need to add finalizers without granting access to the entire resource. It certainly is possible in Kubernetes:
But I can't update finalizers using
client.Client
. I don't have a permission to modify entire deployment andclient.Client
doesn't provide an API to modify generic subresource, it only has special support for "status" subresource. In this PR I add support to other subresources.I'm open to suggestions of course. Consider the initial PR version also as an invitation to discussion even if the implementation is totally wrong.
Fixes #172