You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@camel.apache.org by GitBox <gi...@apache.org> on 2022/11/24 08:28:02 UTC

[GitHub] [camel-k] squakez commented on issue #3831: Build refactoring (to address runtime decoupling)

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

   > This seems a good idea, and would decouple the camel-k-operator from the integration build, which is good for the operator scalability and availability. Related to this shared volume, that is going to grow indefinitely, it would be interesting to have some sort of monitoring, also thinking when upgrading camel-k-operator, and the integrations are rebuilt, the old artifacts won't be used anymore, should they be deleted ?
   
   I guess some sort of monitoring should be provided anyhow. We'll dig into details for sure. For now, I am interested in collecting feedback about possible downside I am not able to see in this draft analysis.


-- 
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