PodSpecable Integration

[astefanutti]

In a growing number of use-cases, it is preferable, or expected, that the Integration resource be PodSpecable.

The main use cases are:

• Knative SinkBinding: Make the Camel K operator more involved in the Knative SinkBinding flow #1976, Make integrations addressable (Knative SinkBinding) #1122
• Service Binding: Upgrade to Service Binding operator to v0.5.0 #2077

It is also useful in the general case, to enable the generic configuration of the Integration pods: #1657.

[johnpoth]

In the case of Service Binding, the specification has alleviated that constraint

[astefanutti]

In the case of Service Binding, the specification has alleviated that constraint

Would that simplify or not to have Integration PodSpec-able w.r.t. Service Binding?

[mmelko]

I can look at this.

[lburgazzoli]

@astefanutti @nicolaferraro wonder if when making making an integration podspecable (but I think also other resources like the kamelet binding can benefit from it), then if I define an image with name "integration" (or whatever we decide to use to identify the integration container), that should be considered as an equivalent of a kit so in that case, no build should be performed

[astefanutti]

@lburgazzoli that sounds logical. There is no need for creating a build whose resulting image is overwritten by the Integration PodSpec.

That can lead to inconsistencies, e.g. with the Dependencies field. Though Pod-Specability is a mechanism that brings high-level of configurability, hence must be used responsibly.

An idea, if we try to map the logic of merging rather than replacing, to container images, could be to use the provided image as the base image?

[nicolaferraro]

@lburgazzoli that sounds logical. There is no need for creating a build whose resulting image is overwritten by the Integration PodSpec.

That can lead to inconsistencies, e.g. with the Dependencies field. Though Pod-Specability is a mechanism that brings high-level of configurability, hence must be used responsibly.

An idea, if we try to map the logic of merging rather than replacing, to container images, could be to use the provided image as the base image?

Yeah, sounds interesting, but I guess the image at the moment misses the relevant metadata (e.g. list of dependencies included) to let us perform merging. Although containers have labels as well...

[astefanutti]

Yeah, sounds interesting, but I guess the image at the moment misses the relevant metadata (e.g. list of dependencies included) to let us perform merging. Although containers have labels as well...

Right, probably better to keep it simple!

[lburgazzoli]

That can lead to inconsistencies, e.g. with the Dependencies field. Though Pod-Specability is a mechanism that brings high-level of configurability, hence must be used responsibly.

We can add validations so i.e. if you put a container image and dependencies, then we fail

[mmelko]

Currently I've created a pod trait that will merge the PodTemplateSpec from the integration into deployment's one. I guess those validation should be done also from the pod trait right? Do we know any other things that shouldn't be replaced/modified ?

[mmelko]

wip PR: #1861 so far without any validations