mertdotcc commented on issue #4126: URL: https://github.com/apache/camel-k/issues/4126#issuecomment-1478008685
Alright, I will try the generic file approach and share my findings. > we should trigger by default a new build when we are in native mode @squakez so what is the officially recommended approach when it comes to using native images for a wide set of integrations in production? The first time I tried running my integrations in native mode, I gave my operator the recommended minimum memory of `4Gi` and the whole build process took way too long for the type of operations I am running. Then I bumped up the requested memory to `8Gi` and gave an upper memory limit of `12Gi`. Keep in mind that I didn't limit `CPU` at all. During the build process, my operator uses all of the memory I basically allocate for it, in this case, all of the `12Gi`, and then takes around 10 minutes to build an image. Imagining a likely scenario of a decent-size team working on integrations and regularly committing their work, it is safe to assume that the operator will be constantly building images 24/7. Do you guys suggest that we only use the non-native build for `development`, `test`, `staging`, etc; and only enable the native build for the `production` environment? This would obviously take a big load off of our operator (and this is something we really need to keep an eye on since Camel-K doesn't support multi-operator high-availability atm) but then I would argue that maintaining and debugging things might get problematic as there _might_ be some different behaviors when we run an integration in native and non-native (see my other open issues), i.e., things working in non-native not properly working in native, etc. Open to suggestions. Thanks in advance! -- 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-unsubscr...@camel.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
