CRUDKubernetesDependentResource not updating the dependent CustomResource when a property is deleted from the spec

[prateekkohli21]

Version - 4.0.0

I am using CRUDKubernetesDependentResource to update dependent CustomResource, it works well when any field is added or updated in the primary resource, but when I try to delete a property from a primary resource spec, dependent CustomResource is not getting updated.

Desired state for the dependent CustomResource is also changing, but it is not getting reflected in the backend.

For eg: Below is our primary resource
kind: CustomResourceKafka
spec:
kafka:
replicas: 3
config:
min.insync.replicas: 2
default.replication.factor: 3

So, when I try to change any value in the config property of primary resource, its reflecting in the dependent resource,
but when I try to remove the config section completely, my dependent resource is not getting updated.

Even when we remove any 1 of the property from config section, then also dependent resource is not getting updated, but the desired state is changing.

So, whenever we remove any properties, it's not getting reflected, but adding & updating is working fine.

[csviri]

Hi @prateekkohli21 are you able to upgrade to the newest version?
A great help would be in case to create a minimal sample where we can reproduce this. It's quite strange since this should be a simple update operation.

[csviri]

yeh, that might be the issue

[prateekkohli21]

we haven't written any custom matcher, we are relying on the default one.

[azhagesanr]

Hi @csviri,
I have created the sample project in the git hub
https://github.com/azhagesanr/kuberenetesoperator_algates

To build:
mvn clean package

After the above command, the crds are generated under target folder:
primary resource crd: target/classes/META-INF/fabric8/exposedapps.io.algates-v1.yml
secondary resource crd: target/classes/META-INF/fabric8/samples.io.algates-v1.yml

Apply both CRD:

kubectl apply -f target/classes/META-INF/fabric8/exposedapps.io.algates-v1.yml
kubectl apply -f target/classes/META-INF/fabric8/samples.io.algates-v1.yml

Run the Operator by
java -cp target/lib/*:target/sampleoperator-0.1.jar:. io.algates.Runner

Primary custom resource is present in
src/main/resources/exposedappresource.yaml

Apply that primary resource
kubectl apply -f src/main/resources/exposedappresource.yaml

Both primary and secondary resources will be created.
Describe primary resource : kubectl describe exposedapps.io.algates/testexposedappalgates
Describe secondary resource: kubectl describe sample/testexposedappalgates

comment out the following property from the src/main/resources/exposedappresource.yaml and then apply.
testobj:
name1: testname4
name2: testname2

Check for both primary resource and secondary resource.. The commented out property will not be in primary resource and still be present in the secondary resource.

Example to reproduce the issue

apiVersion: "io.algates/v1alpha1"
kind: ExposedApp
metadata:
  name: testexposedappalgates
  labels:
    app: algates
spec:
  nameOverride: tesexposeapp
  imageRef: tutum/hello-world
  replica: 6
  #testobj:
    #name1: testname4
    #name2: testname2

[csviri]

thx, will take a look!

[csviri]

@prateekkohli21 the problem is indeed with Matcher. If you take a look, the default matcher works in a way that checks if all the properties on the desired state are the same on the actual (but not if there are additional fields):

https://github.com/java-operator-sdk/java-operator-sdk/blob/34f3e0f023a8804538678b50f5cf615361fbe0bf/operator-framework-core/src/main/java/io/javaoperatorsdk/operator/processing/dependent/kubernetes/GenericKubernetesResourceMatcher.java#L66-L66

This is because admission controllers and built in resource controllers sometimes adds their own default values (like when you create a pod or service or other built in resources). So what you can do now is override the matcher and call the equals methods of specs (pls override those also).

Meanwhile will create an out of the box matcher that is easy to use and will do basically equals.