PatchNamespacedDeploymentWithHttpMessagesAsync provokes a "UnprocessableEntity" exception

[KevinDitschke]

I updated the kubernetes-client from version 2.0.29 to the latest version 3.0.4.
I'm using the method PatchNamespacedDeploymentWithHttpMessagesAsync to exchange the imageversion of a V1Deployment.

I passed a patch with the API object, the name and namespace like this:

var response = await _client.PatchNamespacedDeploymentWithHttpMessagesAsync(patchObject, deployment.Metadata.Name, deployment.Metadata.NamespaceProperty);

It results in this exception:

Reverting the version to 2.0.29 causes the method to work perfectly fine again.

What has changed between the versions, that this exception occurs? Are there properties missing on the patch object?

Thank you in advance!

[brendandburns]

Please see the discussion here:
#476

We had accidentally switched to JSONPatch in 2.0.29, and in 3.0.4 we switched back to Merge Patch.

Unfortunately we need a better option that allows you to choose, but we're not there yet.

[mprigge]

I've read #476 and I'm a little bit confused. The latest 3.0.7 is currently sending patches with a content type of application/merge-patch+json; charset=utf-8. This is resulting in 422 UnprocessableEntity from the API. Manually sending an otherwise identical patch with application/json-patch+json; charset=utf-8 works as expected. I'd been packing a JsonPatchDocument inside of V1Patch as the body. Is there a different means of constructing the patch body we should be using with the latest version which works with this content type?

[tg123]

trying to find a solution to handle custom content type.
then will fix this issue

[narthollis]

I am currently working around this by adding another DelegateHandler to my HttpClient pipeline:

            services
                .AddHttpClient("k8s")
                .ConfigurePrimaryHttpMessageHandler(Configuration.CreateDefaultHttpClientHandler())
                .AddHttpMessageHandler<ForceJsonPatchHandler>()
                .AddHttpMessageHandler(KubernetesClientConfiguration.CreateWatchHandler);
...

    public class ForceJsonPatchHandler : DelegatingHandler
    {
        protected override Task<HttpResponseMessage> SendAsync(HttpRequestMessage request, CancellationToken cancellationToken)
        {
            if (request.Method == HttpMethod.Patch && request.RequestUri.ToString().Contains("/configmaps/"))
            {
                request.Content.Headers.ContentType = new MediaTypeHeaderValue("application/json-patch+json");
            }

            return base.SendAsync(request, cancellationToken);
        }
    }

[RobLSDev]

Are there any code examples available to convert from json patching to merge patching? It seems like all of the existing patch examples in this repository use json, and would be broken by #476

[brendandburns]

Merge patch is described in the RFC here:

https://tools.ietf.org/html/rfc7386

I will fix/update the patch example in the codebase.

[brendandburns]

I sent a PR here:
#517

With a working example.

[RobLSDev]

So that PR includes a changes to the library itself. Am I correct in understanding that the examples won't work until we are on a version of the library that includes that PR?

[brendandburns]

yes, that's correct.

note that you can always use the ReplaceFoo APIs instead of PatchFoo APIs to accomplish the same thing. (though you need to send a complete API object for the resource when you use Replace)

[mihaimyh]

Is the the only way to create patches going forward? Do we need to manually create Json strings?

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

[mihaimyh]

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