Add example about using server-side apply with this client

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?

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

@tdmalone

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!

@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:

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+)
there is a known issue about choosing content-type for PATCH methods. See content-type for patch commands #959

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

/remove-lifecycle stale

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

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

/reopen

@themrmax

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

Details

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.

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

@themrmax

@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

@themrmax

@MoShitrit: Reopened this issue.

Details

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.

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.

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

@fejta-bot

@fejta-bot: Closing this issue.

Details

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.

Any idea if this is feature is still in plan ?

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?

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

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)

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.

Navigation Menu

Repository navigation

Add example about using server-side apply with this client #1093

6 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

	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)

Add example about using server-side apply with this client #1093

Description

Activity

roycaihw commented on Mar 9, 2020

moshevayner commented on Apr 7, 2020

roycaihw commented on Apr 9, 2020

fejta-bot commented on Jul 8, 2020

tdmalone commented on Jul 10, 2020

kwiesmueller commented on Aug 5, 2020

fejta-bot commented on Nov 3, 2020

6 remaining items

themrmax commented on Feb 8, 2021

k8s-ci-robot commented on Feb 8, 2021

themrmax commented on Feb 8, 2021

moshevayner commented on Feb 15, 2021

k8s-ci-robot commented on Feb 15, 2021

Jc2k commented on Feb 16, 2021

fejta-bot commented on Mar 18, 2021

k8s-ci-robot commented on Mar 18, 2021

Buffer0x7cd commented on Oct 7, 2021

zanieb commented on Apr 27, 2022

Jc2k commented on Apr 27, 2022

portswigger-tim commented on Mar 17, 2023

jbnjohnathan commented on May 7, 2023

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions