astefanutti commented on a change in pull request #1861:
URL: https://github.com/apache/camel-k/pull/1861#discussion_r625739973
##########
File path: docs/modules/traits/pages/pod.adoc
##########
@@ -0,0 +1,83 @@
+= Pod Trait
+
+// Start of autogenerated code - DO NOT EDIT! (description)
+ The pod trait allows the customization of the Integration pods.
+ It applies the `PodSpecTemplate` struct contained in the Integration
`.spec.podTemplate` field, into the Integration deployment Pods template, using
strategic merge patch.
+
+ This can be used to customize the container where Camel routes execute, by
using the `integration` container name.
+
+
+This trait is available in the following profiles: **Kubernetes, Knative,
OpenShift**.
+
+// End of autogenerated code - DO NOT EDIT! (description)
+== Example
+We have an integration that will read files from defined folder:
+[source,groovy]
+----
+from('file:///var/log')
+ .convertBodyTo(String.class)
+ .setBody().simple('${body}: {{TEST_VARIABLE}} ')
+ .log('${body}')
+
+----
+The content of the folder might be autogenerated by bash script using a
sidecar container. The pod template could be defined as follows:
+
+[source,yaml]
+----
+containers:
+ - name: integration
Review comment:
Right, we need to decide what is the precedence. I see three layers:
* operator
* user provided pod template
* any other user provided options (that affects the integration pod)
The first decision to make is whether the operator is prescriptive or not,
that is whether it's possible to override the operator defined spec by the
template. Then whether the pod template overwrites other user defined options,
or the other way around. For the later, I would be inclined to think it's
better from an end-user standpoint to have the specific options have precedence
over the more general pod template. For the former, that depends on the level
of power we want to delegate to the users.
--
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.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
