[I] Remove IntegrationKit CRD [camel-k]

["squakez (via GitHub)" <gi...@apache.org>]

squakez opened a new issue, #6455:
URL: https://github.com/apache/camel-k/issues/6455

   ### Requirement
   
   In order to simplify the building system we should remove the CRD. A side effect would be the removal of incremental kits, but the simplification and the possibility to directly leverage the Build the same way we do for self managed Integrations is a great tradeoff to consider.


-- 
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: commits-unsubscribe@camel.apache.org.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org

Re: [I] Remove IntegrationKit CRD [camel-k]

["timmy-mathew-ah (via GitHub)" <gi...@apache.org>]

timmy-mathew-ah commented on issue #6455:
URL: https://github.com/apache/camel-k/issues/6455#issuecomment-4064154420

   @squakez To help us adapt our platform strategy, could you confirm if our understanding of the trade-offs is correct?
   
   1. Removing IntegrationKit means losing incremental builds entirely. Subsequent deployments won't benefit from base layer caching, resulting in slower in-cluster builds ?
   
   2. This signals a broader strategic move toward building images externally in CI/CD pipelines (through github actions -> maven build) etc rather than relying on the operator for heavy Maven builds? Is this correct or if not how would it affect building the integrations with the right dependencies?
   
   Are we interpreting the impact and long-term vision correctly here?


-- 
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: commits-unsubscribe@camel.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org

Re: [I] Remove IntegrationKit CRD [camel-k]

["github-actions[bot] (via GitHub)" <gi...@apache.org>]

github-actions[bot] commented on issue #6455:
URL: https://github.com/apache/camel-k/issues/6455#issuecomment-4703728639

   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!


-- 
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: commits-unsubscribe@camel.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org

Re: [I] Remove IntegrationKit CRD [camel-k]

["squakez (via GitHub)" <gi...@apache.org>]

squakez commented on issue #6455:
URL: https://github.com/apache/camel-k/issues/6455#issuecomment-4068150104

   Hey @timmy-mathew-ah, thanks for the questions, it is important to reason about pros and cons of this possible decision. The main rationale of this move (still potential, nothing is written in stones) is to simplify the operator architecture (which is composed of too many custom resources), make it easier to onboard any alternative runtime to Quarkus, promote to higher environments and also make it the generation of container more secure.
   
   The point you raise in 1 is partially correct. We won't be likely able to benefit the cache of any previous generated intermediate image any longer. However, this is a minor gain that happen in the `packaging` phase, as, the majority of time required to compile is taken by the `build` which has to happen anyway. This delay should only happen in development environments, where we think a few seconds delay can be tolerable. The production environment should always reuse the container built previously (either via self managed build or gitops). One problem we have identified with the incremental image is the possibility to use intermediate layer that have dependencies that may be not needed by your application. Imaging the kit with dependencies A,B,C. Then I want to run an image wich requires A,B only, but the optimization will take in also dependency C.
   Also, in the long term, there is a difficulty to maintain the very high number of Kits that are generated which are never removed.
   
   About point 2, this is not true. We aim to strengthen and simplify the build part. Either it's a simple or complex application, the operator goal is to provide all the building specifically tuned for a Camel application. The possibility to use any CICD is something we put in account, but it's not the main use case scenario. IMO, if you use Camel K is to make it build the application in the operator way.
   
   Hope it clarifies a little bit the future vision and, as for the requirement to use intermediate layer caching, I'll be happy to read more about your use case. Even removing the IntegrationKit, we could reason about alternative way to use existing Integration containers (for example, scanning the Integration dependencies list).


-- 
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: commits-unsubscribe@camel.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org