Revisit configuration options

[lburgazzoli]

As today there is a little bit of confusion about the options to configure the runtime (you can blame me as I introduced them in the early days of camel-k) and I think it is now time to rethink them.

I'm thinking about something like:

--build-property  key=val 
--config-property key=val[@build]
--config          configmap|secret|file:name[/key]
--resource        configmap|secret|file:name[/key][@path]

This issue also relates to:

• Add a new configuration type to set build time properties #1831
• rethink configurations spec #1680

[lburgazzoli]

/cc @astefanutti @squakez

[astefanutti]

I realise from apache/camel-k-runtime#624, that any ConfigMap or Secret is (attempted to be) loaded as properties file.

I'd agree with @lburgazzoli comment from apache/camel-k-runtime#593:

I think the main issue is that we don't have a way to distinguish between configmaps and secrets used to store properties vs resources.

It seems only application properties files should be mounted into the conf.d directory, while other ConfigMaps and Secrets should be mounted on the side. IIUIC, this is what would be for the --config and --resource options for.

So currently, we have the ServiceBindings, ConfigMaps and Secrets mounted under the conf.d directory. Only the ConfigMaps and the Secrets added with the new --config option should be mounted there. The one added with the existing --resource should be mounted in etc/camel/resources.

That also means the existing --configmap and --secret options are removed.

[lburgazzoli]

Yep, I'd also add a new property function on camel-kruntime like resource:name/key to ease the process of loading resources.

[heiko-braun]

Would a configmap resource contain build-properties and config-properties itself?

[squakez]

I am working on this.

[lburgazzoli]

@squakez @nicolaferraro @astefanutti

wondering if we should create a configuration trait at this point so when we will implement #2165, we could also use the same mechanic to attach configuration properties to bindings, kamelets & what not

[astefanutti]

That sound like a good idea worth exploring. If we follow that path, we may want to deprecate the .spec.configuration field from the Integration API/CRD.

[astefanutti]

Also, in that spirit of moving / "encapsulating" the configurability responsibility to the traits, it may be logical to:

• Move the .spec.repositories field (Maven repositories) into the builder trait
• Move the .spec.serviceAccountName field into the pod trait

[squakez]

@squakez @nicolaferraro @astefanutti

wondering if we should create a configuration trait at this point so when we will implement #2165, we could also use the same mechanic to attach configuration properties to bindings, kamelets & what not

Yes, that seems the best path to follow. As we must ensure compatibility, I may follow an approach where I will develop the feature minimizing the impact on the existing code, if I see it makes sense, and then encapsulating the logic into a separate trait.