squakez commented on pull request #2635: URL: https://github.com/apache/camel-k/pull/2635#issuecomment-922735331
> > > Alternatively, an idea would be to keep the `camel` trait, and add these configuration options to it. These are about configuring the Camel runtime after all, and it may be more appealing to users than a more abstract `runtime` name. > > > > > > I've progressed more deeply and I finally realized that the trait that should be in charge of them would be `container`. Basically, when it comes to `config` and `resource` there is the need to attach a volume, and this is done in `container` trait. However there is some incompatibility, see [#2320 (comment)](https://github.com/apache/camel-k/issues/2320#issuecomment-922718785) for more details. > > Yes, that was one of my comment above, if we take the technical standpoint, these configuration bits are ConfigMap or Secret mounted into the Integration Pod(s), so the _pod_ or _container_ traits may already be responsible for related concerns. If we don't find a functional standpoint that works and that would be more relevant to users, we can fallback to this approach (even the container trait is already quite crowed). Then, the `properties` would go to into the `camel` trait? Yes, that's correct. The `properties` would be a perfect fit for `camel` trait. I was more thinking on a general refactoring for all Integration configuration. Let's figure out what we want to do for all the cases first, and I will retake this one later. -- 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
