Received extra event after patch a CR using KubernetesMockServer

[jmformenti]

Describe the bug

When we patch the status for a custom resource using KubernetesMockServer, we are receiving a new event for that custom resource but that is not the expected behaviour. We don't receive any new event in a real Kubernetes cluster for the same action.

This behaviour was found using JOSDK, see: operator-framework/josdk-spring-boot-starter#30, that under the hood is using KubernetesMockServer.

Fabric8 Kubernetes Client version

6.1.1

Steps to reproduce

1. Run this test customServiceReconciler: https://github.com/java-operator-sdk/operator-framework-spring-boot-starter/blob/main/starter-test/src/test/java/io/javaoperatorsdk/operator/springboot/starter/test/EnableMockOperatorTests.java#L68
2. You can see just one log trace: Reconciling: test-name (reconciler worked only one time)
3. Change this line return UpdateControl.updateResource(resource): https://github.com/java-operator-sdk/operator-framework-spring-boot-starter/blob/main/samples/common/src/main/java/io/javaoperatorsdk/operator/springboot/starter/sample/CustomServiceReconciler.java#L56
   by return UpdateControl.patchStatus(resource);
4. Running the test again, now we can see twice: Reconciling: test-name (reconciler worked two times)

Expected behavior

In previous step 4, see only one time the trace Reconciling: test-name

Runtime

other (please specify in additional context)

Kubernetes API Server version

other (please specify in additional context)

Environment

Linux

Fabric8 Kubernetes Client Logs

No response

Additional context

Using KubernetesMockServer

[shawkins]

@jmformenti @csviri there is a bug with the the mock server treatment of a null status that the associated pr addresses.

However there will still be a lingering issue - we don't know how to handle the difference between an explicit null and missing. For example if you manually create a generic resource with:

GenericKubernetesResource gkr = new GenericKubernetesResource();
...
gkr.setAdditionalProperty("status", null);

That will be treated as a different resource than one where the status is omitted entirely. I think there was a similar issue Attila was asking about with diff support.

Unless the mock server is made aware of the nullable / defaulting behavior - https://kubernetes.io/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/#defaulting-and-nullable we don't be able to handle this robustly on the mock side.

[jmformenti]

Thanks a lot @shawkins, maybe we are not affected by the explicit null issue because in our real tests we are using always the status filled