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.

[moshevayner]

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 content-type for patch commands #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.

[themrmax]

/reopen

[k8s-ci-robot]

@themrmax: You can't reopen an issue/PR unless you authored it or you are a collaborator.

In response to this:

/reopen

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.

[themrmax]

@MoShitrit how did you go with this? i would very much like this feature

[moshevayner]

@MoShitrit how did you go with this? i would very much like this feature

Hey @themrmax
I haven't really looked at it since. Might be a good time to re-evaluate, given that it's been about a year and we passed a few versions and iterations already.
If anyone's willing to take a stab at it- please feel free. Otherwise I'll try myself whenever I can put some time aside to do so.
Thanks!

/reopen

[k8s-ci-robot]

@MoShitrit: Reopened this issue.

In response to this:

@MoShitrit how did you go with this? i would very much like this feature

Hey @themrmax
I haven't really looked at it since. Might be a good time to re-evaluate, given that it's been about a year and we passed a few versions and iterations already.
If anyone's willing to take a stab at it- please feel free. Otherwise I'll try myself whenever I can put some time aside to do so.
Thanks!

/reopen

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.

[Jc2k]

I believe this PR from 2019 would enable the use of server side apply? #959. It enables you to set the content type, and AIUI that means you can do content_type=application/apply-patch+yaml when calling any patch API and enjoy SSA.

[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-contributor-experience at kubernetes/community.
/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-contributor-experience at kubernetes/community.
/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.

[Buffer0x7cd]

Any idea if this is feature is still in plan ?

[zanieb]

It'd be great to know if this feature was available without subclassing the client. Are there any existing examples of using server-side apply from the Python client?

[Jc2k]

I am still adding a subclass to every project, unfortunately.

[portswigger-tim]

Anyone who lands here... there's an example within the tests:

python/kubernetes/base/dynamic/test_client.py

Lines 512 to 532 in 56eea10

	def test_server_side_apply_api(self):
	client = DynamicClient(api_client.ApiClient(configuration=self.config))
	api = client.resources.get(
	api_version='v1', kind='Pod')
	name = 'pod-' + short_uuid()
	pod_manifest = {
	'apiVersion': 'v1',
	'kind': 'Pod',
	'metadata': {'labels': {'name': name},
	'name': name},
	'spec': {'containers': [{
	'image': 'nginx',
	'name': 'nginx',
	'ports': [{'containerPort': 80,
	'protocol': 'TCP'}]}]}}
	resp = api.server_side_apply(
	namespace='default', body=pod_manifest,
	field_manager='kubernetes-unittests', dry_run="All")
	self.assertEqual('kubernetes-unittests', resp.metadata.managedFields[0].manager)

[jbnjohnathan]

2 years since Server-Side apply was introduced in Kubernetes 1.22. Would be great to get to use it fully in this kubernetes python client soon.