kubebuilder
kubebuilder copied to clipboard
Add Server Side Apply documentation to the book
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
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
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.
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 https://github.com/kubernetes-sigs/controller-runtime/pull/1365 to land, etc. I'm still very fresh on kubebuilder and everything related, but definitely willing to contribute ;-)
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: https://github.com/kubernetes-sigs/controller-runtime/pull/1365 why it should be a blocker for us? Do you see any reason?
Hi @camilamacedo86 ,
Thanks for your reply! About https://github.com/kubernetes-sigs/controller-runtime/pull/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 :-)
Would be nice if controller-gen
could be updated to automatically generate the applyconfiguration
code!
Would be nice if
controller-gen
could be updated to automatically generate theapplyconfiguration
code!
I found this abandoned PR:
- https://github.com/kubernetes-sigs/controller-tools/pull/536
In https://github.com/kubernetes-sigs/kubebuilder/issues/2514#issuecomment-1050623865 @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 https://github.com/kubernetes-sigs/controller-runtime/issues/1669#issuecomment-921242074 but haven't been able to find an example.
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
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.
Not yet - was first waiting for an answer to check whether this approach would make sense before start typing a lot of code ;-)
/remove-lifecycle stale
Hi @wmuizelaar,
If you are looking for an answer over: https://github.com/kubernetes-sigs/kubebuilder/issues/2514#issuecomment-1050623865. I think the best approach would to be create a section on the docs and a sample-specific to help people know how to work with.Is that make sense? WDYT?
So, please feel free to also check the docs and propose a PR doing changes as you see fit so then we can move from there.
Hi @camilamacedo86 - that does make sense! I'll give it a first draft after my holidays ;-)
Thank you @wmuizelaar and sorry for the delay. I did not realize that you were waiting for any response. Btw, thank you for looking at that. It is a very nice contribution 🥇
The PR: https://github.com/kubernetes-sigs/controller-tools/pull/536 shows has relevance to this task either.
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
Hi @wmuizelaar how is your holidays going ? Do we have any update for the state of these docs ?
Juli 2023. Before creating docs it needs to be implemented: https://github.com/kubernetes-sigs/controller-tools/pull/536
I have the gut feeling, that server-side-apply is something which was invented by very smart people. Unfortunately most people (like me) are not that smart, and that's the reason why SSA in CRDs are not solved yet.
Maybe Patch is enough for most cases, and SSA is not needed?
But I am new to operator development and kubebuilder. Maybe I am completely wrong.