squakez opened a new issue, #3831: URL: https://github.com/apache/camel-k/issues/3831
One of the hot topic we're discussing recently is about the possibility to decouple Camel K Runtime and have it bundled as a Camel Quarkus provider in order to remove dependency problem in the release cadence. One important thing we should address is how we're removing such dependency from the Build as right now the Camel K Operator container image is inheriting from the [Mandrel image expected by the latest runtime](https://github.com/apache/camel-k/blob/main/build/Dockerfile#L16) in order to be able to perform the build. I thought we could review the way we're building the Integrations in the following way:  This idea is the merge the two actual building strategy we have in place, `pod` and `routine`. In this new scenario we always schedule a kubernetes `job` in order to perform the build (which is nothing else than a `mvn package`) but we share a `volume` in order to keep cached the maven dependencies downloaded. Each different builder is the one which knows which container image to use in order to do the build, based on the runtime version provided in the Integration. Advantages on adopting this model: - Implicit builds scalability (we can have more than 1 in parallel) - Possibility to run more than 1 runtime version by the same operator - No loss of dependencies - Have more that one operator sharing the same Maven repository cache - No loss of cache if operator is killed/rescheduled to other nodes - Operator has a loose dependency on the runtime (it must know the container runtime, but it does not inherit from it) This is a draft idea, but I'd like to have some opinion before going deep into details, I may not see some pitfall at this stage yet. cc @lburgazzoli @astefanutti @oscerd @claudio4j @christophd @zbendhiba @tadayosi -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
