Patching of a Custom Resource does not work in v6.1.1

[danpfe]

Have a custom resource, defined as:

@Group("mysamplegroup")
@Version("v1")
public class Sample extends CustomResource<SampleSpec, SampleStatus> implements Namespaced {
 // ...
}

When I do client.resource(some_Default_Resource_Such_As_A_Pod).patch(); it works just fine, doing the same on the above custom resource simply does nothing.

Doing it the old and deprecated way client.customResource(Sample.class).inNamespace("default").withName("something").patch(myCustomResource); works, however.

Is this a bug or am I misunderstanding something about the new API?

Thanks!

[rohanKanojia]

Looks like a bug to me, somehow it seems to be sending same object as base and updated ones and generating incorrect diff.

[danpfe]

Don't know if that helps but here is the "sample-operator" that I updated to 6.1.1 and that I used as template to build other operators (that worked with the legacy API): https://github.com/codelair-io/example-k8s-operator-java/tree/master/src/main/java/io/codelair/examples/kubernetesoperator

[shawkins]

it works just fine, doing the same on the above custom resource simply does nothing.

@danpfe @rohanKanojia the logic is the same either way. I think there's a problem no matter which resource type you use.

This is a regression with #4142 I think the intent of the change was so that patch(item) methods would be against the current item, rather than what was from the server - resource(item1).patch(item2) will create a diff between item1 and item2, which is also consistent with how the edit and accept methods worked. With the patch() call it's just diffing to itself.

I think that it's better to have the patch() method specifically update the context to ensure the server side item is used, rather than going back to always loading the server side item as the base.

[manusa]

I think that it's better to have the patch() method specifically update the context to ensure the server side item is used, rather than going back to always loading the server side item as the base.

I'm not sure if this would apply to all patch strategies.

[danpfe]

it works just fine, doing the same on the above custom resource simply does nothing.

@danpfe @rohanKanojia the logic is the same either way. I think there's a problem no matter which resource type you use.

Hi @shawkins. I can retest this. I have a private operator that I can't share here where I believe patch() worked on another resource but maybe I just confused it with other modifier-methods.

[shawkins]

I'm not sure if this would apply to all patch strategies.

@manusa this issue only affects JSON patches when there is a context item and no item passed in - that's only the patch() or the patch(context) methods.

[danpfe]

it works just fine, doing the same on the above custom resource simply does nothing.

@danpfe @rohanKanojia the logic is the same either way. I think there's a problem no matter which resource type you use.

Hi @shawkins. I can retest this. I have a private operator that I can't share here where I believe patch() worked on another resource but maybe I just confused it with other modifier-methods.

So I checked, you're right. patch() doesn't work no matter the resource, patchStatus() seems to works though :)

[shawkins]

patchStatus() seems to works though

Yes that is a json merge, not a json patch, so no diff is needed.