search

apache / camel-k

Apache Camel K is a lightweight integration platform, born on Kubernetes, with serverless superpowers
https://camel.apache.org/camel-k
Apache License 2.0
848 stars 345 forks source link

Evaluate how we can fully support fa(s)t-jar execution #5539

Open squakez opened 1 month ago

squakez commented 1 month ago

While working on #5488 I realized we have certain limitations/assumptions in the way we require to execute the jvm from the Camel application container Pod. It turns out that, due to the usage of Joor and its limitations (see [1]) we cannot make a reliable usage of the fast-jar (and eventually fat-jar if/when we move to managed Springboot).

I think the root cause is coming from the fact that we're loading the routes dynamically, ie, we create a generic project, and at runtime we inject the route into the Camel context and start it (please, @lburgazzoli correct me if this is wrong). This was a cornerstone of the reusability of an IntegrationKit which spared some time to build a new project. However, I wonder if this is a design we still want to maintain as it gives us certain limitations, and, remove the parity between a normal Camel (Quarkus) development and Camel K.

If we instead let the build to consider the route at runtime, we should be able to use the fa(s)t-jar and leverage the default Camel mechanism to load a route. Of course, the trade off is that we would be losing the possibility to reuse the same IntegrationKit for different Integrations as, each of them would be including the route into the build. We should understand if this design can still be compatible with incremental image [2] (I think it does, since the route would be contained in the built dependency which is going to be replaced in the new Kit created).

This is something to address in a major release, as it would break existing Integrations compatibility, but I think that it is a good opportunity to collect feedback to be ready when this is coming.

[1] https://github.com/jOOQ/jOOR/issues/69 [2] https://camel.apache.org/camel-k/next/architecture/incremental-image.html

squakez commented 1 month ago

The redesign of this part would probably gives us the possibility to move to a jre (and distroless) base image, reducing the CVE surface area and the size of each image (see also #3743)

Exether commented 1 week ago

This looks like an interesting move to me also. Currently when we update the kamelets we have issues with inconsistency between the kamelets' definitions and the dependencies already contained in the images (Explained in this forum's post).

Having all routes and dependencies inside the image would definitely avoid this issue.