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
