feat: import external Camel applications

[squakez]

With this PR we enable the possibility to import any Camel application deployed on Kubernetes manually or via other tooling and be able to monitor it as a "synthetic" Integration.
We can control the same deployment objects we are using for managed Integrations: Deployment, CronJob and Knative Services.

It works by annotating the specific object we want to import with the camel.apache.org/integration=my-it label. The operator creates a synthetic Integration and monitor the resources after the object which created it. In order to monitor the sibling Pods, we need the user to properly add an annotation in the resource template.

$ kubectl label deploy my-camel-sb-svc camel.apache.org/integration=my-it
$ kubectl patch deployment my-camel-sb-svc --patch '{"spec": {"template": {"metadata": {"labels": {"camel.apache.org/integration": "my-it"}}}}}'
$ k get it
NAME    PHASE     RUNTIME PROVIDER   RUNTIME VERSION   KIT   REPLICAS
my-it   Running                                               1
$ k scale deploy my-camel-sb-svc --replicas 2
$ k get it
NAME    PHASE     RUNTIME PROVIDER   RUNTIME VERSION   KIT   REPLICAS
my-it   Running                                               2
$ k delete deploy my-camel-sb-svc
deployment.apps "my-camel-sb-svc" deleted
$ k get it
NAME    PHASE                 RUNTIME PROVIDER   RUNTIME VERSION   KIT   REPLICAS
my-it   Application Missing                                                  0

We're covering the main corner cases such as removal of the object which generated the import or the missing selector which would not allow the possibility to monitor the sibling pods. It's a MVP that sets the framework for any possible future feature around monitoring.

Release Note

feat: import external Camel applications

[github-actions]

🐫 Thank you for contributing!

Code Coverage Report ⚠️ - Coverage changed: 33.6% --> 33.3% (Coverage difference: -.3%)

[lburgazzoli]

quick comment before looking at the code: we can maybe simplify it by using a static label camel.apache.org/supervise=true and take the name of the deployment/etc/

[squakez]

quick comment before looking at the code: we can maybe simplify it by using a static label camel.apache.org/supervise=true and take the name of the deployment/etc/

Unfortunately not. Or at least, it would not be that easy. The way we are watching objects is quite limited to the presence of the camel.apache.org/integration label. If we remove such a requirement, we'd need to watch all objects. You will see later that we already had to remove the filter from Pods, in order to be able to watch also the non managed ones. I think that if we remove this constraint we may degrade the performance too much.

[lburgazzoli]

quick comment before looking at the code: we can maybe simplify it by using a static label camel.apache.org/supervise=true and take the name of the deployment/etc/

Unfortunately not. Or at least, it would not be that easy. The way we are watching objects is quite limited to the presence of the camel.apache.org/integration label. If we remove such a requirement, we'd need to watch all objects. You will see later that we already had to remove the filter from Pods, in order to be able to watch also the non managed ones. I think that if we remove this constraint we may degrade the performance too much.

mh, I see.
we may need to think how to make the process simpler

[github-actions]

🐫 Thank you for contributing!

Code Coverage Report ⚠️ - Coverage changed: 33.6% --> 33.3% (Coverage difference: -.3%)

[github-actions]

🐫 Thank you for contributing!

Code Coverage Report ⚠️ - Coverage changed: 33.6% --> 33.5% (Coverage difference: -.1%)

[github-actions]

🐫 Thank you for contributing!

Code Coverage Report ⚠️ - Coverage changed: 33.6% --> 33.5% (Coverage difference: -.1%)

[github-actions]

🐫 Thank you for contributing!

Code Coverage Report ⚠️ - Coverage changed: 33.6% --> 33.5% (Coverage difference: -.1%)

[github-actions]

🐫 Thank you for contributing!

Code Coverage Report ✔️ - Coverage changed: 33.6% --> 34.1% (Coverage difference: +.5%)

[github-actions]

🐫 Thank you for contributing!

Code Coverage Report ✔️ - Coverage changed: 33.6% --> 34.1% (Coverage difference: +.5%)

[github-actions]

🐫 Thank you for contributing!

Code Coverage Report ✔️ - Coverage changed: 33.6% --> 34.1% (Coverage difference: +.5%)

[squakez]

An additional comment which may be useful in the future. Before reaching this state, I've worked on a few experiments. The result of them may return useful eventually.

The first experiment was to let the operator assume the control of the managed fields of a Deployment: 1e4aaaa#diff-de2d026ce0dc415e68ee971f300e7320de019cc68c5171cf76425859587f1a85 - this solution was discarded because it clearly overlap the external deployment procedure (ie, triggering a new deployment).

The second one had the same problem (overlapping external deployment): https://github.com/squakez/camel-k/tree/feat/it_import_delete_deploy - in this case we were deleting the deployment, in order to let the operator create and manage one from scratch.

Although they are aggressive approaches, they may be used eventually in a sort of "dry-run" operation to let the user decide if a given deployment can be substituted with a managed Integration (at the price of forcefully deleting the original deployment).

[github-actions]

🐫 Thank you for contributing! 🐫

Unable to create Coverage Report ⚠️.
Merge conflicts found.

[squakez]

@lburgazzoli I think I've addressed the concerns of your last review. About the possibility to miss an event, now this should be covered by the same monitoring action which is in charge to be reconciled and eventually capture any possible missing delete event.

[github-actions]

🐫 Thank you for contributing!

Code Coverage Report ✔️ - Coverage changed: 33.6% --> 34.2% (Coverage difference: +.6%)

[github-actions]

🐫 Thank you for contributing!

Code Coverage Report ✔️ - Coverage changed: 33.6% --> 34.2% (Coverage difference: +.6%)