[Trait] Configuration refactoring

[squakez]

As commented in #2003, we should introduce a new Configuration trait in order to properly encapsulate the logic of the different configurations provided into an Integration. This new capability would simplify the configuration of traits as also expressed in #2165.

Once developed we can deprecate .spec.configuration.

I am tracking this as a spin off issue to be worked after finishing #2003, as the latter will aim to remove configurations that may be part of this new trait.

[squakez]

I will work on this after #2003

[squakez]

I've analyzed this more deeply. It is possible to think a trait, probably container trait, to handle --config and --resource, moving the parsing logic directly in the trait (which is also in charge to mount the volumes, so it even simplify the "modularity").

However we have a big limitation when it comes to file usage. The file content must be stored within the same Integration, so that it can be transformed on the fly into a configmap and used. The trait is executed by the operator and it won't have access to the file content (unless we store it previously, as we're doing now).

One possibility would be to get rid of file. After all, the user should have familiarity with cloud native way of storing resources (ie, configmap) and create them beside the integration. The same would apply to --openapi and would deprecate .integration.spec.resources as well.

@astefanutti @nicolaferraro @lburgazzoli wdyt?

[astefanutti]

One possibility would be to get rid of file. After all, the user should have familiarity with cloud native way of storing resources (ie, configmap) and create them beside the integration. The same would apply to --openapi and would deprecate .integration.spec.resources as well.

Right. Alternatively, the kamel run CLI could be responsible for creating the ConfigMap corresponding to the file: config option. to avoid that two-stepped experience. Anyway, I agree we should avoid storing arbitrary files into the Integration resources.

[squakez]

One possibility would be to get rid of file. After all, the user should have familiarity with cloud native way of storing resources (ie, configmap) and create them beside the integration. The same would apply to --openapi and would deprecate .integration.spec.resources as well.

Right. Alternatively, the kamel run CLI could be responsible for creating the ConfigMap corresponding to the file: config option. to avoid that two-stepped experience. Anyway, I agree we should avoid storing arbitrary files into the Integration resources.

Yeah, I thought the same, but we even complicate the process as we need to parse twice. The first time in the cmd in order to process the content, the second time in the trait as we need to locate the resource. Moreover, I am not sure if we would actually able to scale or recreate the Pod properly. Right now we leverage the presence of the content in the Integration, if we create an attached configmap we will have to make sure this is not deleted unless the user is deliberately deleting the Integration. I think we can enter in a dangerous path.

[astefanutti]

One possibility would be to get rid of file. After all, the user should have familiarity with cloud native way of storing resources (ie, configmap) and create them beside the integration. The same would apply to --openapi and would deprecate .integration.spec.resources as well.

Right. Alternatively, the kamel run CLI could be responsible for creating the ConfigMap corresponding to the file: config option. to avoid that two-stepped experience. Anyway, I agree we should avoid storing arbitrary files into the Integration resources.

Yeah, I thought the same, but we even complicate the process as we need to parse twice. The first time in the cmd in order to process the content, the second time in the trait as we need to locate the resource. Moreover, I am not sure if we would actually able to scale or recreate the Pod properly. Right now we leverage the presence of the content in the Integration, if we create an attached configmap we will have to make sure this is not deleted unless the user is deliberately deleting the Integration. I think we can enter in a dangerous path.

You're right, but I think Camel K should not concern about it. This should be delegated to the underlying Kubernetes controller, like the Deployment controller, as much as possible. For example, if the user deletes the ConfigMap, the Deployment controller will handle it. For the use case of responding to changes, it's also a vast area with long standing issues like kubernetes/kubernetes#22368.

[squakez]

The previous commits were relating this issue, but not closing it.