Integrations remain in Initialization loop when referenced config map has owner references

[lsergio]

What happened?

The created Integration keeps rebuilding itself when a config map with ownerReferences is used.

Steps to reproduce

Consider scenario where an Integration references a ConfigMap in the Mount trait:

apiVersion: camel.apache.org/v1
kind: Integration
metadata:
  name: myintegration
spec:
  sources:
  - name: main.groovy
    content: |-
      from("quartz://Scheduler_Trigger?cron=*+*+*+*+*")
          .to("direct:start")

      from("direct:start")
        .to("https://httpbin.org/delay/2?bridgeEndpoint=true")
        .to("log:info")
  traits:
    mount:
      resources:
      - configmap:myconfigmap

Create that Integration in the cluster, which will not start because the configmap is not there yet.

After the integration is created, query its uid:

k get it myintegration -oyaml | grep uid
  uid: abc42efa-87a8-43ec-b412-183bb1539cd6

Now create the config map using that uid in the ownersReferences:

apiVersion: v1
data:
  foo: "1"
  bar: "2"
kind: ConfigMap  
metadata:
  name: myconfigmap
  ownerReferences:
  - apiVersion: camel.apache.org/v1
    blockOwnerDeletion: true
    controller: true
    kind: Integration
    name: myintegration
    uid: abc42efa-87a8-43ec-b412-183bb1539cd6

Result: the Integration will not build. It wil stay in a loop between the statuses "Building Kit" and "Initialization".
The operator log shows constant messages about the Integration being rebuilt.

And integration digest in its status keeps changing.

Relevant log output

{"level":"info","ts":"2024-01-26T14:45:38Z","logger":"camel-k.controller.integration","msg":"State transition","request-namespace":"f6g7h8i9j0","request-name":"myintegration","api-version":"camel.apache.org/v1","kind":"Integration","ns":"f6g7h8i9j0","name":"myintegration","phase-from":"Building Kit","phase-to":"Initialization"}
{"level":"info","ts":"2024-01-26T14:45:38Z","logger":"camel-k.controller.integration","msg":"Initializing Integration","request-namespace":"f6g7h8i9j0","request-name":"myintegration","api-version":"camel.apache.org/v1","kind":"Integration","ns":"f6g7h8i9j0","name":"myintegration"}
{"level":"info","ts":"2024-01-26T14:45:39Z","logger":"camel-k.controller.integration","msg":"State transition","request-namespace":"f6g7h8i9j0","request-name":"myintegration","api-version":"camel.apache.org/v1","kind":"Integration","ns":"f6g7h8i9j0","name":"myintegration","phase-from":"Initialization","phase-to":"Building Kit"}
{"level":"info","ts":"2024-01-26T14:45:39Z","logger":"camel-k.controller.integration","msg":"Initializing Integration","request-namespace":"f6g7h8i9j0","request-name":"myintegration","api-version":"camel.apache.org/v1","kind":"Integration","ns":"f6g7h8i9j0","name":"myintegration"}
{"level":"info","ts":"2024-01-26T14:45:39Z","logger":"camel-k.controller.integration","msg":"State transition","request-namespace":"f6g7h8i9j0","request-name":"myintegration","api-version":"camel.apache.org/v1","kind":"Integration","ns":"f6g7h8i9j0","name":"myintegration","phase-from":"Initialization","phase-to":"Building Kit"}
{"level":"info","ts":"2024-01-26T14:45:39Z","logger":"camel-k.controller.integration","msg":"Integration needs a rebuild","request-namespace":"f6g7h8i9j0","request-name":"myintegration","api-version":"camel.apache.org/v1","kind":"Integration","ns":"f6g7h8i9j0","name":"myintegration"}
{"level":"info","ts":"2024-01-26T14:45:39Z","logger":"camel-k.controller.integration","msg":"State transition","request-namespace":"f6g7h8i9j0","request-name":"myintegration","api-version":"camel.apache.org/v1","kind":"Integration","ns":"f6g7h8i9j0","name":"myintegration","phase-from":"Building Kit","phase-to":"Initialization"}
{"level":"info","ts":"2024-01-26T14:45:39Z","logger":"camel-k.controller.integration","msg":"Initializing Integration","request-namespace":"f6g7h8i9j0","request-name":"myintegration","api-version":"camel.apache.org/v1","kind":"Integration","ns":"f6g7h8i9j0","name":"myintegration"}

Camel K version

2.2.0

[lsergio]

Removing the ownerReferences from the ConfigMap stops the loop, but will keep the ConfigMap in the cluster.
Currently I'm using ownerReferences to make sure the resources asssociated with the Integration are also deleted when the Integration is deleted.

[lsergio]

The same issue might happen with secrets as well, but I haven't tested this scenario

[lsergio]

With 1.12.x that scenario worked for me. I compared https://github.com/apache/camel-k/blob/release-1.12.x/pkg/util/digest/digest.go to https://github.com/apache/camel-k/blob/main/pkg/util/digest/digest.go and noticed that in 1.12.x configmaps and secrets were not used in the digest calculation

[squakez]

Yes, that's a side effect of #4665 thanks for reporting. In fact, I think that we should improve this feature by only looking watching those resources with a given label like it happens for the other objects associated to an Integration.

[Exether]

The same issue might happen with secrets as well, but I haven't tested this scenario

I confirm, we had the same issue with secrets generated (and owned) by VaultOperator.

[squakez]

This should have been closed and will be fixed in 2.3.0.