Default operator.id annotation

[squakez]

I've noticed that if we run an Integration without the camel.apache.org/operator.id annotation, then, the behavior is to use the namespace operator where this is stored. However, when we kamel run/bind, there is a forced setting to camel.apache.org/operator.id: camel-k that may interfere when a user is interested in getting the Integration back (ie -o yaml) and later pushing the Integration to the cluster in any given namespace. Should we remove the presence of default operator.id: camel-k? is there any particular reason why we want to leave it there @christophd ?

[christophd]

I've noticed that if we run an Integration without the camel.apache.org/operator.id annotation, then, the behavior is to use the namespace operator where this is stored

I do not think that this is the current behavior. From what I know all resources that are missing the camel.apache.org/operator.id annotation should only be handled by the default global operator (id=camel-k). The namespace where the default operator and the integration resource are located in is not relevant in this scenario.

So in my eyes using the default annotation camel.apache.org/operator.id: camel-k and skipping the annotation completely should have the same effect. Both resources should be handled by the default operator (id=camel-k) regardless of the namespace.

Does that make sense?

[squakez]

Interesting. Then there must be some bug because I installed 2 operators in separate namespace (development and production) none is global. Later I'm running an Integration without operator.id annotation in both namespaces and both operators are reconciling the Integration correctly in each of their namespaces. Notice that I'm very happy to have this behavior, reason why I was wondering why we need to explicitly include the annotation when we want to default it to the namespace on which we install the Integration. Also, this behavior simplify the promote subcommand across namespaces.

[christophd]

so in your scenario there is no default global operator (id=camel-k) involved?

[christophd]

IMO in future support for non global operators should be dropped and everything should be controlled by the operator id only.

[squakez]

Nope. And even if it was there, I'd expect that both Integration were reconciled by the supposed global one. In my case, the operator installed in the given namespace seem to control properly the Integration installed in its namespace (again, I am very happy with this behavior).

[christophd]

In my case, the operator installed in the given namespace seem to control properly the Integration installed in its namespace (again, I am very happy with this behavior)

As soon as you would add a default global operator to your scenario things will change and you might have two operators reconciling the very same resource. I think your scenario currently only works for backward compatibility reasons.

I think it would be better to use two different operator ids instead of relying on the circumstance that local resources in your current namespace belongs to the operator installed in that very same namespace.

[MehrCurry]

I installed camel-k via the latest helm chart (using helm template through ArgoCD).

The operator picks up intergrations without the camel.apache.org/operator.id: camel-k annotation as expected. But when i deploy an integration with that annotation explicitly set the operator ignores it.

As understand this discussion it shouldn't make a difference.

[github-actions]

This issue has been automatically marked as stale due to 90 days of inactivity.
It will be closed if no further activity occurs within 15 days.
If you think that’s incorrect or the issue should never stale, please simply write any comment.
Thanks for your contributions!