chore: gitops and plain Quarkus docs

docs/modules/ROOT/pages/architecture/runtime.adoc

@@ -5,8 +5,6 @@ image::architecture/camel-k-runtimes.jpg[runtimes, width=1024]
 
 Camel runtime application is in charge to bridge the output produced by the operator during a `Build` to the Camel runtime. It will finally execute an application containing the `Route` as defined by `Camel K` user. It will take care of converting all the different configuration and tuning into something meaningful to `Apache Camel` framework. We use a java application, `camel-k-runtime` which is based on `camel-quarkus` to achieve the goal.
 
-NOTE: This document reflects Camel K version 1.6. It may not reflect slight changes developed after this review.
-
 [[runtime-quarkus]]
 == Based on Camel Quarkus
 
@@ -19,16 +17,15 @@ Learn more in the xref:camel-quarkus::index.adoc[Camel Quarkus documentation sec
 [[runtime-duties]]
 == Runtime main duties
 
-The main goal of the Camel-k-runtime is to launch a Camel Quarkus application and setup the routes configured by the Camel K user. When a user run a new `Integration`, the xref:architecture/operator.adoc[`Operator`] will take care of building an application containing the `camel-k-runtime dependency`. During application startup, the camel-k-runtime will be in charge to take care of the following aspects:
+The main goal of the Camel-k-runtime is to launch a Camel Quarkus application and setup the routes configured by the Camel K user. When a user run a new `Integration`, the xref:architecture/operator.adoc[`Operator`] will take care of building an application basing it on Camel K Runtime dependency.
+
+[[plain-quarkus]]
+== Plain Camel Quarkus runtime
 
-* Sources loading
-* Properties setting
-* Cron
-* Knative
-* Kamelet
-* Master
-* Webhook
+More recently we are working to make it easier and run a Camel Quarkus application out of the box instead. You're strongly recommended to use the `plain-quarkus` Camel trait runtime provider for any Integration you're running. You can do this following the example:
 
-Basically the application will apply the configuration/customizations needed to run your application on Camel, transforming those configuration coming from the `Integration` spec into something meaningful to Camel framework.
+```shell
+kamel run test.yaml -t camel.runtime-provider=plain-quarkus
+```
 
-NOTE: Camel-k-runtime is a very fast evolving project. You may find more relevant details accessing directly to the https://github.com/apache/camel-k-runtime[application source code].
+NOTE: we plan to graduate plain Camel Quarkus runtime as default runtime in the future (likely in the next major release).

docs/modules/ROOT/pages/running/promoting.adoc

@@ -64,3 +64,85 @@ When you use the `promote` subcommand, you're also keeping the status of any con
 This is particularly nice when you have certain traits which are requiring the scan the source code (for instance, Service trait). In this way, when you promote the new Integration, the traits will be automatically configured to copy any parameter, replicating the very exact behavior between the source and destination environment.
 
 With this approach, you won't need to worry any longer about any trait which was requiring the source to be attached in order to automatically scan for features.
+
+[[gitops]]
+== GitOps
+
+NOTE: this feature is available starting from version 2.6
+
+The promote has also the possibility to create a Kustomize based overlay structure in order to simplify the creation of a **GitOps based deployment** process. Let's pretend we want to create a GitOps pipeline for two environments, as an example, *staging* and *production*. For each environment we can call the export command:
+
+```
+$ kamel promote promote-server -n development --to staging --export-gitops-dir /tmp/integrations
+$ kamel promote promote-server -n development --to production --export-gitops-dir /tmp/integrations
+```
+
+NOTE: you can call this command for as many environments you manage
+
+The result will be a directory with the following structure:
+
+```
+$ tree /tmp/integrations/
+/tmp/integrations/
+└── promote-server
+    ├── base
+    │   ├── integration.yaml
+    │   └── kustomization.yaml
+    ├── overlays
+    │   ├── production
+    │   │   ├── kustomization.yaml
+    │   │   └── patch-integration.yaml
+    │   └── staging
+    │       ├── kustomization.yaml
+    │       └── patch-integration.yaml
+    └── routes
+        └── PromoteServer.java
+
+6 directories, 7 files
+```
+The `promote-server` directory contains the Integration named as `promote-server` (the one we created in the previous chapter). Then, you can see a *base* directory which contains the base Integration custom resource. Additionally you will find the *staging* and *production* overlays which contains the patches you may want to apply in each given environment.
+
+```
+$ cat /tmp/integrations/promote-server/overlays/production/patch-integration.yaml
+apiVersion: camel.apache.org/v1
+kind: Integration
+metadata:
+  creationTimestamp: null
+  name: promote-server
+spec:
+  traits:
+    mount:
+      configs:
+      - configmap:my-cm
+status: {}
+```
+
+The CLI has a predetermined set of configuration (traits) which are typically subject of environment patching, such as Camel properties or any Kubernetes resource configuration. You will need to change those parameters accordingly or add any one else required for your specific use case.
+
+The above structure could be used directly with `kubectl` (eg, `kubectl apply -k /tmp/integrations/promote-server/overlays/production`). For this reason it can be used *as is* to feed a Git repository and referenced in any CICD pipeline.
+
+=== Running Camel with ArgoCD
+
+Once you have stored the project in a Git repository, if you're using a CICD technology like https://argo-cd.readthedocs.io[ArgoCD] you can run immediately your *production* pipeline as:
+
+```
+argocd app create my-ck-it-prod --repo https://git-server/repo/promote-server.git --path overlays/production --dest-server https://kubernetes.default.svc --dest-namespace prod
+```
+
+From this moment onward any change can be performed on the repository and it will be automatically refreshed by the CICD pipeline accordingly.
+
+NOTE: any other CICD technology can be adopted using the Git repository as source.
+
+=== Predetermined configuration
+
+The CLI will add a patch configuration for any of the following trait configuration found in the source base Integration:
+
+* Affinity configuration
+* Camel properties
+* Container resources
+* Environment variables
+* JVM options
+* Mount configuration
+* Toleration configuration
+
+NOTE: feel free to ask to add any further configuration you require.

docs/modules/ROOT/pages/running/running.adoc

@@ -92,6 +92,32 @@ spec:
 
 You can see the specification is a lot neater, so, try choosing Yaml DSL whenever it's possible.
 
+== Runtime provider
+
+Camel K was originally equipped with a dedicated runtime known as Camel K Runtime. This is a lightweight layer on top of Camel Quarkus. However, you can directly run plain regular Camel Quarkus runtime applications as well. You will learn the concept of traits later on. For now, just be aware that you can run any Integration setting the plain Quarkus runtime using `camel` trait configuration. Here an example of how that would be:
+
+```yaml
+apiVersion: camel.apache.org/v1
+kind: Integration
+metadata:
+  name: my-plain-quarkus-it
+spec:
+  flows:
+  - from:
+      parameters:
+        period: "1000"
+      steps:
+      - setBody:
+          simple: Hello Camel from ${routeId}
+      - log: ${body}
+      uri: timer:yaml
+  traits:
+    camel:
+      runtimeProvider: plain-quarkus
+```
+
+NOTE: we plan to graduate plain Camel Quarkus runtime as default runtime in the future (likely in the next major release). We therefore recommend to use the plain Camel Quarkus runtime in any of your Integrations already.
+
 == Using Kamel CLI
 
 Camel K works very well with any Kubernetes compatible user interface (such as CLI as `kubectl`, `oc` or any other visual tooling). However we do provide a simple CLI that helps you performing most of the Integration works in an easier fashion: it's xref:running/running-cli.adoc[`kamel` CLI].