Python: Add example about using server-side apply with this client

[tdmalone]

What is the feature and why do you need it:

I would like to have an 'apply' (patch) mode for the helpful create_from_yaml/create_from_dict utility methods.

I currently use this to automate deployment of our application, however from time-to-time something goes wrong in the deployment and we need to deploy it again. At the moment we can't re-run the automation, because parts of it fail due to some objects having already been created.

I'm looking at catching the FailToCreateError and checking for reason: "AlreadyExists", but at this point it would be wonderful to be able to run create_from_yaml in an 'apply'/patch mode, rather than have to build out the full request myself.

Describe the solution you'd like to see:

Probably something as simple as an apply=True or patch=True argument on these methods could do the job?

[roycaihw]

Server-side apply has been beta since 1.15, we should add example/utility about how to use it with the 11.0 client.

[MoShitrit]

Hey @tdmalone & @roycaihw!
I'm willing to start contributing to this project, and this issue seems like it might be a great first one to begin with!
So I just wanted to make sure I have the right idea in mind- is the goal here to add an additional apply/patch logic to https://github.com/kubernetes-client/python/blob/master/kubernetes/utils/create_from_yaml.py? I didn't dive in too deep yet, but from a quick glimpse, it seems like adding a method apply_from_yaml_single_item and calling it when apply=True was passed could do it.
Alternatively, we can probably separate that entirely by creating a whole new module for apply_from_yaml.py, but I assume there will be a good bit of repetition if we take that route.
Either way, I'd love to take a stab at this! Please let me know how we can kick off a quick discussion around it.
Thanks much, and I'm looking forward to start working on that!

[roycaihw]

@MoShitrit Welcome and thanks for looking into this issue!

Yes I think the goal is to add an apply mode to the utility methods, either adding an apply=True option or automatically retrying when an AlreadyExists error is returned. To achieve that I think we should use the new server-side apply feature (implementing a client-side apply like kubectl apply from scratch will be expensive and doesn't make much sense when we have server-side apply almost ready).

To begin with, I think we can first add an example about how to use this API in the python client. According to the doc, a client requests a server-side apply by sending an API request to any PATCH endpoint with content type application/apply-patch+yaml and a partially specified object in the body.

Did a little research and I think there are currently two blockers for using this API in the python client:

1. although server-side apply targeted to be beta in 1.15, it seems that it actually went beta in 1.16 (as the doc shows). For this client, we do code-generation based on the upstream openapi spec. The problem is that the 1.15 openapi spec didn't specify application/apply-patch+yaml as acceptable content type. And 1.16 openapi spec specified that. As a result, the generated client will only have application/apply-patch+yaml concept starting 1.16 (12.0.0a1+)
2. there is a known issue about choosing content-type for PATCH methods. See https://github.com/kubernetes-client/python/pull/959

[fejta-bot]

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle stale

[tdmalone]

/remove-lifecycle stale

[kwiesmueller]

Hey there,
we are currently investigating options for adding apply to client-go. If you need help with adding it to the python client, feel free to get in touch on Slack https://kubernetes.slack.com/archives/C0123CNN8F3
I'm adding our label to put this on our list as well.
/wg api-expression

[fejta-bot]

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle stale

[fejta-bot]

Stale issues rot after 30d of inactivity.
Mark the issue as fresh with /remove-lifecycle rotten.
Rotten issues close after an additional 30d of inactivity.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle rotten

[fejta-bot]

Rotten issues close after 30d of inactivity.
Reopen the issue with /reopen.
Mark the issue as fresh with /remove-lifecycle rotten.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/close

[k8s-ci-robot]

@fejta-bot: Closing this issue.

In response to this:

Rotten issues close after 30d of inactivity.
Reopen the issue with /reopen.
Mark the issue as fresh with /remove-lifecycle rotten.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/close

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.