WIP ✨ (go/v4): Add support to Server-Side Apply#5458
WIP ✨ (go/v4): Add support to Server-Side Apply#5458camilamacedo86 wants to merge 1 commit intokubernetes-sigs:masterfrom
Conversation
0d291e1 to
60416fd
Compare
60416fd to
d24e315
Compare
10a43a3 to
0725248
Compare
971b7d3 to
fd92b49
Compare
9069709 to
7bba449
Compare
|
|
||
| // Apply - only manages the fields you specified above | ||
| // User's custom labels/annotations are preserved! | ||
| if err := r.Patch(ctx, resource, client.Apply, client.ForceOwnership, |
There was a problem hiding this comment.
Just for my own culture, is proning client.ForceOwnership a result of "a single resource should not be managed by multiple operator" logic ?
There was a problem hiding this comment.
Updated. Good catcher !!!
7bba449 to
b4130bd
Compare
b4130bd to
00e30de
Compare
00e30de to
b206c73
Compare
This comment was marked as resolved.
This comment was marked as resolved.
b206c73 to
6fb93ef
Compare
Add --ssa flag to create api command for scaffolding APIs with Server-Side Apply support. Uses template conditions instead of code injection where possible.
|
@camilamacedo86: The following tests 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. DetailsInstructions 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. I understand the commands that are listed here. |
| Use this flag when: | ||
|
|
||
| - **Multiple controllers manage the same resource**: Your controller manages some fields while other controllers or users manage others | ||
| - **Users customize your CRs**: Users add their own labels, annotations, or spec fields that your controller shouldn't overwrite | ||
| - **Partial field management**: You only want to manage specific fields and leave others alone | ||
| - **Avoiding conflicts**: You want declarative field ownership tracking to prevent accidental overwrites | ||
|
|
There was a problem hiding this comment.
I'm not quite sure on how to phrase it, but should we also say "Expect other people to automate your CRs through higher level operators" ?
As in the operator that has generated SSA types would not be the one using them but merely providing them for other operators to import ?
yyewolf
left a comment
There was a problem hiding this comment.
That's a really nice improvement, I can't wait to try it and we (at my company) will have a lot of work to do to use this as effectively as possible 🔥
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: camilamacedo86, yyewolf The full list of commands accepted by this bot can be found here. The pull request process is described here DetailsNeeds approval from an approver in each of these files:
Approvers can indicate their approval by writing |
| } | ||
|
|
||
| // Apply using SSA - only manages the fields specified above | ||
| if err := r.Patch(ctx, resource, client.Apply, |
There was a problem hiding this comment.
Stumbled on this PR while searching for recommendations on SSA for kubebuilder controllers. looks like client.Apply is deprecated. Is this still the way to do SSA?
This PR adds a new
ssa/v1-alphaplugin that scaffolds APIs with controllers using Kubernetes Server-Side Apply (SSA) patterns. How that works: See the doc added: https://deploy-preview-5458--kubebuilder.netlify.app/reference/server-side-apply.htmlWhat is it?
Server-Side Apply helps when multiple actors (your controller, users, other controllers) need to manage different fields of the same resource. Instead of overwriting the entire object, SSA tracks field ownership and only updates the fields you explicitly manage.
Usage
What it scaffolds
After running make generate, you get type-safe apply configuration helpers:
Closes: #2514
Closes: #5237