claudio4j commented on issue #4166: URL: https://github.com/apache/camel-k/issues/4166#issuecomment-1558024280
There are three types of camel-k traits 1) Traits that just sets runtime properties in application.properties. The trait properties in this case are just short friendly names. The properties may be consumed from the different libraries: camel, camel-quarkus, quarkus Some of these properties such as customizers or loaders are specific behavior set by camel-k-runtime. Examples: addons/telemetry, addons/resume, addons/vault/* 2) Traits that in addition to setting runtime properties, also creates or modifies k8s objects, such as Role, RoleBindings, Container, etc. Examples: cron, knative, prometheus, master 3) Traits that manipulates only k8s objects. These are not the target of the trait redesign. Examples: keda, deployment, 3scale, jolokia, health, etc. There is camel-catalog that drives the artifacts and dependency resolution according to the runtime, the camel-catalog is generated by camel-k-runtime. There is a capabilities section in camel-catalog that could be enhanced to add more information such as allowed properties, runtime provider and hard dependencies. With this approach the addons/vault/* trais can be removed, then in this case the user has to use the long camel property names, example: Using `kamel run` and the trait with short property names: ``` -t aws-secrets-manager.use-default-credentials-provider -t telemetry.endpoint ``` No traits, setting the runtime property: ``` -p camel.vault.aws.defaultCredentialsProvider -p quarkus.opentelemetry.tracer.exporter.otlp.endpoint ``` In this example, having the short properties enhances the user experience at the expense of having a hard dependency to the runtime property (camel quarkus or camel). In the case the user wants to use a non quarkus runtime, there should be an intermediate layer to decide how the trait behavior should be used for the runtime. This intermediate layer can be camel-k-runtime. The Cron trait has some additional behavior: * a shutdown route strategy when all messages in the exchange has been processed (by camel-k-runtime) * option to use either a k8s CronJob or a pure camel cron (backed by timer, quartz, cron) This was just an example, to collect some feedback about the necessity to have an intermediate layer to negotiate the behavior between camel-k operator and the target runtime. As of today there is camel-k-runtime, that is going to be this intermediate layer. -- 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
