Skip to content

Commit

Permalink
chore(doc): camel runtimes adjustment
Browse files Browse the repository at this point in the history
  • Loading branch information
@squakez
squakez committed Aug 28, 2024
1 parent eba0187 commit 89cfeac
Showing 1 changed file with 6 additions and 254 deletions.
260 changes: 6 additions & 254 deletions docs/modules/ROOT/pages/running/camel-runtimes.adoc
View file
Original file line number Diff line number Diff line change
Expand Up @@ -17,262 +17,14 @@ The step above is a very quick way to create a basic Camel application in any of

At this stage we do have a container image with our Camel application. We can use the `kamel` CLI to run our Camel application via `kamel run --image docker.io/my-org/my-app:1.0.0` tuning, if it's the case, with any of the trait or configuration required. Mind that, when you run an Integration with this option, the operator will create a **synthetic** IntegrationKit.

NOTE: certain traits (ie, JVM) won't be available when running an application built externally.

If all is good, in a few seconds (there is no build involved) you should have your application up and running and you can monitor and operate with Camel K as usual.

[[traits-and-dependencies]]
== Traits and dependencies

Certain Camel K operational aspect may be driven by traits. When you're building the application outside the operator, some of those traits may not be executed as they are executed during the building phase that we are skipping when running **sourceless Integrations**. Here we provided a list of those traits that may not work when building the application outside the Camel K operator.

NOTE: this is a best effort analysis taking as reference the work available in version 2.3.

* Build column show those traits that affects the build (will be skipped for sourceless Integrations).
* Dependencies column show those traits that will add some dependency (you may need to manually add those dependencies).
* Runtime column show those traits that will influence the runtime, mostly via properties (you may need to manually add those properties to the bundled `application.properties`).
* Deployment column show those traits that will be executed for the deployment (nothing should be required).

[cols="1,1,1,1,1"]
|===
|Trait
|Build
|Dependencies
|Runtime
|Deployment

|Affinity
|x
|x
|x
|v

|Builder
|v
|x
|x
|x

|Camel
|x
|x
|v
|x

|Container
|x
|x
|x
|v

|Cron
|x
|v
|v
|x

|Dependencies
|v
|v
|x
|x

|Deployer
|x
|x
|x
|v

|Deployment
|x
|x
|x
|v

|Environment
|x
|x
|x
|v

|Error Handler
|x
|v
|x
|x

|GC (Garbage Collector)
|x
|x
|x
|v

|Health
|x
|v
|v
|v

|Ingress
|x
|x
|x
|v

|Istio
|x
|x
|x
|v

|Jolokia
|x
|v
|v
|v

|JVM
|x
|x
|v
|v

|Kamelets
|x
|x
|v
|x

|Knative Service
|x
|x
|x
|v

|Knative
|x
|v
|x
|x

|Logging
|x
|x
|v
|v

|Mount
|x
|x
|x
|v

|Openapi
|x
|v
|v
|v

|Owner
|x
|x
|x
|v

|PDB
|x
|x
|x
|v

|Platform
|x
|x
|x
|v

|Pod
|x
|x
|x
|v

|Prometheus
|v
|v
|x
|x

|Pull Secret
|x
|x
|x
|v

|Quarkus
|v
|x
|x
|x

|Service
|x
|x
|x
|v

|Service Binding
|x
|x
|v
|v

|Toleration
|x
|x
|x
|v

|Keda
|x
|x
|x
|v

|Master
|v
|v
|v
|x

|Resume
|v
|v
|x
|x

|Strimzi
|x
|x
|x
|v

|Telemetry
|x
|x
|v
|x
[[camel-runtime-discovery]]
== Camel Runtime version discovery

|Three Scale
|x
|x
|x
|v
Every Camel application requires a `CamelCatalog` object to know how to perform certain runtime configuration. When you run a **sourceless Integrations** there is no easy way to automatically discover for which runtime your application was built. In this case, we suggest you to specify the `camel.runtime-version` trait in order to improve the compatibility between the operator configuration and the specific runtime you're running. If no runtime version is specified, then, as default, the operator will use the one specified in the IntegrationPlatform.

|Vaults
|x
|v
|v
|x
[[traits]]
== Trait configuration

|===
Certain Camel K operational aspect may be driven by traits. When you're building the application outside the operator, some of those traits may not be executed as they are executed during the building phase that we are skipping when running **sourceless Integrations**. There is also no possible way to auto-tune certain traits that require the presence of the source. In this case, you should instead provide a trait configuration with the values that are required by your Integration (for example, Knative, Service and other deployment traits).

0 comments on commit 89cfeac

Please sign in to comment.