Add Server Side Apply documentation to the book

[wmuizelaar]

What do you want to happen?

Hi,

On the blogpost about Server Side Apply becoming GA, it references that when it's ready, the kubebuilder-book will be updated with examples. See https://kubernetes.io/blog/2021/08/06/server-side-apply-ga/#using-server-side-apply-in-a-controller

Is there an issue in this or in one of the related repositories that I could follow? I'm now trying to use it, and while receiving nice examples on slack, and finding all kinds of ways to implement it online, I'm still struggling a lot. A reference in the book would be really appreciated. So if there is not an issue, consider this as a feature request please ;-)

Extra Labels

/kind documentation

[camilamacedo86]

If I properly understood it, shows that we could create a plugin to work with. See: https://book.kubebuilder.io/plugins/plugins.html

Let's see what others also think about it. Also, please feel free to contribute to it. Your contribution is very welcome as well.

Begin a threat at: https://kubernetes.slack.com/archives/CAR30FCJZ/p1645534614215639

[rashmigottipati]

Based on the discussion in triage, we need to update the documentation on Kubebuilder for cronjob tutorial (as the first step) on using server side apply. We need to look into other places we have to update documentation in Kubebuilder to reflect server side apply, updates/patches.

If we update the documentation, we should clarify the caveats as well - that users should not be trying to use server side apply with standard API types.

[wmuizelaar]

I'm willing to help out writing updated documentation on this, but some guidance on what would be a good place / structure would be much appreciated. I.e. - should it replace the current documentation, should it be added as a new chapter, do we want to wait for kubernetes-sigs/controller-runtime#1365 to land, etc. I'm still very fresh on kubebuilder and everything related, but definitely willing to contribute ;-)

[camilamacedo86]

Hi @wmuizelaar,

The thoughts raised at the meeting today was:

• Server Side Apply to make things easier so we could change the tutorial to use it by default
• Then, we could add its caveats
• By last when it is not recommended
• and how to do without Server-Side Apply

About: kubernetes-sigs/controller-runtime#1365 why it should be a blocker for us?
Do you see any reason?

[wmuizelaar]

Hi @camilamacedo86 ,

Thanks for your reply! About kubernetes-sigs/controller-runtime#1365 the following: as I understood, with Server-Side Apply you cannot use the standard API types anymore. There are 2 ways to actually submit resources:

• using unstructured.Unstructured objects (which could be generated from go:embed yaml-templates), with the downside of not being able to use the typed structs anymore
• using applyconfigurations, where you can use those to have typing validation. But this route requires the above PR to be merged, it's currently not working without.

So based on this, what could be an approach is:

• first update the code examples to go for the unstructured.Unstructured-route (since that works)
• write docs about it, including the caveats
• and when the PR is merged, another alternative route could be added to the docs to show an example on how to use the applyconfigurations

Does that make sense? If so, I'd like to volunteer to work on this :-)

[arianvp]

Would be nice if controller-gen could be updated to automatically generate the applyconfiguration code!

[wallrj]

Would be nice if controller-gen could be updated to automatically generate the applyconfiguration code!

I found this abandoned PR:

• ✨ Generation of typed apply clients controller-tools#536

[wallrj]

In #2514 (comment) @wmuizelaar wrote:

using unstructured.Unstructured objects (which could be generated from go:embed yaml-templates), with the downside of not being able to use the typed structs anymore

Did you make any progress on this? I've seen this technique mentioned by @coderanger in kubernetes-sigs/controller-runtime#1669 (comment) but haven't been able to find an example.

[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