io.quarkus:quarkus-kubernetes-client regression

[ikovalyov]

Describe the bug

Quarkus is sending different requests to k8s in java and native build. Native build version is getting 422 Unprocessable Entity responses while java build version doesn't have this issue.

This issue does not exist with io.quarkus-quarkus-kubernetes-client:2.16.6.Final We see this issue on a io.quarkus-quarkus-kubernetes-client:3.2.6.Final

Expected behavior

Both java and native build have same behaviour

Actual behavior

On a version 3.2.6 The Java requests are using Json Patch with such format:

[
  {"op":"replace","path":"/metadata/annotations/item","value":"--version--"},
  {"op":"add","path":"/metadata/resourceVersion","value":"--version--"},
  {"op":"add","path":"/data","value":{"entry.json":"{--- entry body ---}"}}
]

The native binary is using Jsun Patch with different format:

[
  {"op":"replace","path":"/metadata/annotations/item","value":"--version--"},
  {"op":"add","path":"/metadata/resourceVersion","value":"--verson--"},
  {"op":"add","path":"/data/entry.json","value":"{--- entry body ---}"}
]

On a version 2.16.6 Both Java and native build use same format:

[
    {"op":"replace","path":"/metadata/annotations/item","value":"--version--"},
    {"op":"add","path":"/data","value":{"entry.json":"--entry body--"}}
]

How to Reproduce?

No response

Output of uname -a or ver

No response

Output of java -version

No response

Quarkus version or git rev

No response

Build tool (ie. output of mvnw --version or gradlew --version)

Apache Maven 3.9.4 (dfbb324ad4a7c8fb0bf182e6d91b0ae20e3d2dd9)

Additional information

No response

[quarkus-bot[bot]]

/cc @geoand (kubernetes), @iocanel (kubernetes)

[geoand]

cc @manusa

[manusa]

Hi, In the issue description, I can't see the difference between what the client sends in JVM and native mode, it seems to be the same (maybe a bad copy-paste?)

[manusa]

OK, I see it now. It seems to be the last line, with the lack of the entry.json for native.

I'm assuming this is a ConfigMap. Could you please provide more context about what you're doing? (method call, ConfigMap content, etc.)

[ikovalyov]

From our side we are updating config maps indeed.

    @Inject
    KubernetesClient client;

we later update config maps via

        client.configMaps().withLabel(marker).resources().forEach(
                resource -> resource.edit(
                        configMap -> new ConfigMapBuilder(configMap)
                                .addToData(name, content)
                                .editMetadata().addToAnnotations("annotation_name", configVersion).endMetadata()
                                .build()
                )
        );

[ikovalyov]

It's indeed a last line difference {"op":"add","path":"/data","value":{"entry.json":"{--- entry body ---}"}} vs {"op":"add","path":"/data/entry.json","value":"{--- entry body ---}"}

[ikovalyov]

Also at this moment we switched to a

        for (Resource<ConfigMap> resource : client.configMaps().withLabel(label).resources().toList()) {
            resource.item().setData(data);
            resource.item().getMetadata().getAnnotations().put("annotation_name", configVersion);
            resource.item().getMetadata().setManagedFields(null);
            resource.forceConflicts().serverSideApply();
        }

approach which seems to be working fine

[manusa]

I can't really understand how this behavior is changing in native. Seems like the JsonDiff library is acting out.

approach which seems to be working fine

With this you mean that your initial problem has been fixed by switching to serverSideApply and that we can consider this issue as complete?

[ikovalyov]

Well.. It is a workaround which is using different way to apply changes to k8s. But original issue is still there.

Do you think I should create similar issue report for JsonDiff?

[manusa]

Maybe create a mirror issue on the Fabric8 Kubernetes Client so that we can track and analyze the specific client diffing problem from there 🙏

[geoand]

Has an issue been created upstream so we can follow progress there?