-
Notifications
You must be signed in to change notification settings - Fork 3.3k
Fix DynamicClient.server_side_apply #1850
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Fix DynamicClient.server_side_apply #1850
Conversation
DynamicClient.server_side_apply is designed to accept a dict or a ResourceInstance as body. However, if a dict or a ResourceInstance is passed actually, an error occurs because RESTClientObject.rest cannot interpret the Content-Type application/apply-patch+yaml. So, modify RESTClientObject.rest to treat application/apply-patch+yaml as other json-based Content-Types.
|
Welcome @kariya-mitsuru! |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
/lgtm
@abikouo any thoughts? |
resp = api.server_side_apply( | ||
name=name, namespace='default', body=body, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
body=body
Does this mean users can no longer pass JSON as the body? Is this considered a breaking change?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It would be a breaking change, though I'm not sure that we intended for this to accept a string in the first place. Could add a little bit of logic to server_side_apply to attempt to yaml load the content in order to preserve that behavior if it's what we want
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not sure that we intended for this to accept a string in the first place
I agree. I'm okay with calling it out as a breaking change in the release notes. We could provide instruction/util to help users switch/keep the behavior, but the default behavior doesn't have to accept a string.
/lgtm /hold |
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: fabianvf, kariya-mitsuru, roycaihw The full list of commands accepted by this bot can be found here. The pull request process is described here
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
lgtm, it makes sense!! |
/unhold |
What type of PR is this?
/kind bug
What this PR does / why we need it:
DynamicClient.server_side_apply
is obviously designed to accept adict
or aResourceInstance
asbody
like other methods.(This is why the
name
andnamespace
parameters are treated as optional.)However, if a
dict
or aResourceInstance
is passed actually, an error occurs becauseRESTClientObject.rest
cannot interpret theContent-Type
application/apply-patch+yaml
.So, modify
RESTClientObject.rest
to treatapplication/apply-patch+yaml
as other json-basedContent-Type
s.Which issue(s) this PR fixes:
Special notes for your reviewer:
Does this PR introduce a user-facing change?
Yes.
Additional documentation e.g., KEPs (Kubernetes Enhancement Proposals), usage docs, etc.: