astefanutti commented on issue #3831: URL: https://github.com/apache/camel-k/issues/3831#issuecomment-1326136065
Thanks @squakez for the detailed proposition. If I may rephrase the proposal, to better scan the solution space, it proposes to find a solution to both: - Have the ability to dynamically choose the tooling dependencies that are used for the builds, specifically here the bits required to support Quarkus native builds - While still achieving the same level of performance provided by the current "static" solution (mainly the `routine` build strategy) Before jumping into the possible implementations, here are my first feedback: * The current architecture has emerged as a way to minimise the impact on ease / flexibility of _installability_, so solutions relying on persistent volumes have somehow been left aside (Kaniko with warming is an example). To decide to leverage that mechanism, I think we should review what storage classes and dynamic provisioning mechanisms are provided by the Kubernetes platforms that are supported, and the impacts on the installation modes. For examples, do Minikube or KinD support local persistant volumes, PVC / dynamic provisioning? How provisioning of persistant volumes work when installing Camel K via OLM? What are the storage classes provided by the cloud providers? * To really achieve true decoupling, init containers will have to use to implement the Job, so other build steps relying on Camel K bits do not intersect with those of Quarkus. The later point really makes me think that what we try to achieve here is the ability to "inject" build tools dynamically. (Persistant) volumes are one way to achieve this, and are somehow already used to decouple the publish strategy like Buildah and Kaniko, but there may be other ways to be doing it. Currently we do it by "image inheritance", for the JDK, Maven, and Quarkus bits. Are we sure the only way is via persistant volumes? Just to make sure we've scanned the solution space entirely :) -- 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]
