Redesign traits that have runtime dependencies

[squakez]

As we're discussing to let Camel K deploy any Camel application for the future, we should identify those traits that have runtime dependencies and redesign them to make generic allowing any future runtime to be able to use it. There may be cases very specific (such as Quarkus trait which only belongs to Camel Quarkus runtime) where it makes sense to delegate such trait in the runtime or in the specific builder.

[claudio4j]

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.

[claudio4j]

The master trait has a different behavior compared to the other traits, in that the master trait is backed by camel-kubernetes, requires runtime properties.
But the camel-quarkus-kubernetes requires build time properties.
As they are different requirements by two runtimes, the camel-k-runtime would have to negotiate this behavior if the user wants to use camel or camel-quarkus runtimes.

[lburgazzoli]

I'm not sure we should use properties as it seems a little bit confusing to me, as example, if you want to configure something related to the memory consumed by a pod, then using a property seems to be misleading as that's usually something you pass to the runtime.

It will also leak some property to the user which may them rely on them which would increase our maintenance cost.

In some of the previous conversation we had, we discussed:

• camel-k to define a contract with the runtime which could be a simple set of properties that are set by camel-k for a specific feature, but such properties are not supposed to be used by or exposed to users directly
• the runtime part to implement the required machinery to fulfill the contract when possible in the form of a camel quarkus extension or spring boot starter or something else in the future
• the runtime to provide its catalog and related capabilities (which only require to define if it is available and what are the related dependencies)
• the runtime to provide its building tools/image (i.e. as part of the info present in the catalog)

[lburgazzoli]

The master trait has a different behavior compared to the other traits, in that the master trait is backed by camel-kubernetes, requires runtime properties. But the camel-quarkus-kubernetes requires build time properties.

What are the build time properties we need for camel-k ?

[squakez]

I second Luca's comment.

• camel-k to define a contract with the runtime which could be a simple set of properties that are set by camel-k for a specific feature, but such properties are not supposed to be used by or exposed to users directly

Additionally I suggest you to perform an iterative approach instead of a complete design ahead of time, as there are many details that would be difficult to analyze without testing and experimenting. In a very high level analysis I realized that the majority of runtime configuration we slip into the operator are runtime dependencies. I'd start focusing on this development that seems to be quite relevant and later moving on other aspects of the problem.

As I suggested in some earlier conversation, we can include such dependencies in the catalog, and let discover them by the operator when building the application. The new catalog can look like:

apiVersion: camel.apache.org/v1
kind: CamelCatalog
metadata:
  name: camel-catalog-3.20.1-snapshot
...
spec:
  runtime:
	version: 3.20.1-SNAPSHOT
...
  	dependencies:
	- groupId: org.apache.camel.k
  	artifactId: camel-k-runtime
	capabilities:
...
  	traits:
    	jolokia:
      	  dependencies:
      	  - groupId: org.apache.camel.quarkus
            artifactId: camel-quarkus-management
...

That development has to be performed on the Camel K runtime and later the same mechanism exposed for any other runtime we eventually support.
On the operator side, if the trait is enabled, instead of having the trait business logic to take care and set the dependency like we're doing now, we should have an action that scan the list of traits enabled, match it against the catalog chosen for the build and takes care of adding the required dependencies accordingly. That would be a big first step towards decoupling.

[claudio4j]

@lburgazzoli

These seems very much what we have today in camel-k-runtime catalog in the capabilities section, except there is no spring boot provider yet.

What are the build time properties we need for camel-k ?

When I changed master trait to use camel-quarkus-kubernetes, I had to retrieve the resource type and name, from the build property, that change was not merged into camel-k, so there is no build time property to use in camel-k currently.
https://github.com/claudio4j/camel-k/blob/502717d48fbe0e7d08c9e12d9a521ab571756cc8/addons/master/master.go#L172

Perhaps extracts the capabilities logic from GenerateCatalogMojo (camel-k-maven-plugin) to make it easier to onboard other runtimes.

Pasquale suggestion seems the shortest path to experiment with the quarkus provider.

Thank you for the comments.

[lburgazzoli]

These seems very much what we have today in camel-k-runtime catalog in the capabilities section, except there is no spring boot provider yet.

With one but quite relevant difference that instead of having camel-k knowing the properties to set, camel-k declares what properties it will set (if needed) when the trait is active and the runtime translates it into what it needs to materialize the requirement (in term of properties).

When I changed master trait to use camel-quarkus-kubernetes, I had to retrieve the resource type and name, from the build property, that change was not merged into camel-k, so there is no build time property to use in camel-k currently. https://github.com/claudio4j/camel-k/blob/502717d48fbe0e7d08c9e12d9a521ab571756cc8/addons/master/master.go#L172

I think we could evaluate to have a dedicated extension in quarkus if it make sense, like camel-quarkus-master-kubernetes and have it enabled by default when the extension is added. I think as today it is disabled as the master component is part of the camel-quarkus-kubernetes extensions so enabling it by default would enable it for every integration.

TL:DR; I believe we must have some better collaboration between the runtimes and camel-k as having camel-k keeping track of the runtime changes/needs is going to be challenging in the long term.

Perhaps extracts the capabilities logic from GenerateCatalogMojo (camel-k-maven-plugin) to make it easier to onboard other runtimes.

This whole thing should be moved to the runtime part, I don't expect to have the camel-k-runtime anymore but have a camel-k extension in quarkus , camel-k starter in spring boot and all the related runtime specific tooling (maven plugins, builder images, etc)