-
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鈥檒l occasionally send you account related emails.
Already on GitHub? Sign in to your account
馃尡Add a Client wrapper that sets the field owner #1474
Conversation
This lets us put a meaningful name which shows up as `manager` in the `managedFields` of objects.
Hi @bboreham. 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: bboreham 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 |
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 basic tests would also be good :)
/ok-to-test
@@ -0,0 +1,46 @@ | |||
package fieldowner |
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 think this would be better in pkg/client, ppl might not find it here
} | ||
|
||
type clientWithOwner struct { | ||
client.Client |
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'd prefer not to embedd the Client, because should we extend the Client in the future with a method that needs wrapping, the clientWithOwner
won't do that but the code will still compile.
return c.Client.Update(ctx, obj, append(opts, c.owner)...) | ||
} | ||
|
||
func (c *clientWithOwner) Patch(ctx context.Context, obj client.Object, patch client.Patch, opts ...client.PatchOption) 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.
Delete
doesn't need it? I intuitively would have expected Delete
to make you owner of metadata.DeletionTimestamp
(but haven't actually checked)
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, me too, but the FieldOwner
type does not coerce to a DeleteOption
.
I wonder if @DirectXMan12 who seems to have authored that in #435 has a view?
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.
Based off of this and some of the comments @alvaroaleman made, I was wondering about whether we could look at extending the Client itself with a WithOpts(opts ...interace{}) Client
kind of method that would allow the client to store options and add the options to every request where the provided option coerces to the correct kind of option?
That would be more generic and would allow you to use this for other things, eg you could create a DryRun client by adding the DryRun option
Thanks for joining the discussion; it's a point I had not considered.
That sort of interface will quietly do nothing if you set things up wrongly, which is unpleasant to debug. I'm not averse to adding |
Yeah that's a very good point 馃
I just had a look and I think you're right, there isn't much value in the generic option wrapper at the moment, it wouldn't be that useful apart from field owner and dry run (maybe useful for other options in the future but let's not prematurely optimise). |
We already have a wrapper for DryRun and for Namespacing. Building a generic wrapper that takes an option and maybe uses type assertions to apply them as applicable sounds like a good idea to me. We could probably then replace the existing DryRun wrapper and this new Field wrapper with a constructor to this generic implementation. |
Issues go stale after 90d of inactivity. If this issue is safe to close now please do so with Send feedback to sig-contributor-experience at kubernetes/community. |
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:
You can:
Please send feedback to sig-contributor-experience at kubernetes/community. /lifecycle rotten |
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:
You can:
Please send feedback to sig-contributor-experience at kubernetes/community. /close |
@k8s-triage-robot: Closed this PR. In response to this:
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. |
This lets us put a meaningful name which shows up as
manager
in themanagedFields
of objects.As used for example at kubernetes-sigs/cluster-api#4428