-
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
⚠ Client Server side apply #2702
base: main
Are you sure you want to change the base?
Conversation
Signed-off-by: Troy Connor <[email protected]>
Skipping CI for Draft Pull Request. |
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: troy0820 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 |
/test all |
@troy0820: The following test failed, say
Full PR test history. Your PR dashboard. Please help us cut down on flakes by linking to an open issue when you hit one in your PR. 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. I understand the commands that are listed here. |
This feels wrong, but may be right? Any feedback is definitely appreciated. I do know that the test failed on core object without the type meta because I didn't get the gvk of the client.Object before converting, however this isn't tested against a CRD. Also, not sure if we want to allow applyconfigurations or just deal with the unstructured parts we are tryin to "apply". Didn't want to try to resolve this myself as this may need discussion. |
@@ -347,6 +348,21 @@ func (c *client) Patch(ctx context.Context, obj Object, patch Patch, opts ...Pat | |||
} | |||
} | |||
|
|||
func (c *client) Apply(ctx context.Context, obj Object, fieldOwner string) 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.
Pretty heavily opposed to do anything in here before kubernetes/kubernetes#118138 is done because:
- The only type that can be used in here is
unstructured.Unstructured
- The converting as you do it down below doesn't fix the issue that the normal types end up putting zero values in fields
- Which is the reason why applytypes exist, but you can not actually use applytypes here, because they do not fulfill
client.Object
/hold
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.
Definitely hold, and no strong opinions on the feedback beyond understanding the gaps that exists. Waiting on this make sense and provided the support going forward, strategy around this seems crucial. Here for that conversation.
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.
The whole topic boils down to "someone needs to do the work":
- The upstream issue I mentioned needs fixing, upstream signaled that they are ok with the idea but no one has shown up to actually put the work in
- This PR needs to be finished: [WIP] ✨ Generation of typed apply clients using upstream generator controller-tools#818
- A change like this in controller-runtime that adds an
Apply
method that only accepts apply types
The Kubernetes project currently lacks enough contributors to adequately respond to all PRs. This bot triages PRs according to the following rules:
You can:
Please send feedback to sig-contributor-experience at kubernetes/community. /lifecycle stale |
The Kubernetes project currently lacks enough active contributors to adequately respond to all PRs. This bot triages PRs according to the following rules:
You can:
Please send feedback to sig-contributor-experience at kubernetes/community. /lifecycle rotten |
I can close this PR but I wanted to track the work that's necessary and the conversation from this review. The apply types that are needed from controller-tools still has a WIP PR out, and the method must accept apply types. /remove-lifecycle rotten |
/lifecycle frozen |
@sbueringer: The 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-sigs/prow repository. |
The Kubernetes project currently lacks enough contributors to adequately respond to all PRs. This bot triages PRs according to the following rules:
You can:
Please send feedback to sig-contributor-experience at kubernetes/community. /lifecycle stale |
/remove-lifecycle stale |
This is an attempt at server side apply being applied to the
client.Writer
interface.