[
https://issues.apache.org/jira/browse/CAMEL-21036?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17870987#comment-17870987
]
Claus Ibsen commented on CAMEL-21036:
-------------------------------------
Ah okay so you want to use standard camel property placeholders style {{myKey}}
and then "magically" automatic detect config-maps/secret files from a given
folder and load these.
The camel-kubernetes only works for "secret:" and "configmap:" style where you
explicit declare and use this (no magic).
We have to be mindful that Camel users run camel in different runtimes and also
standalone, and that the camel-core project is "neutral".
So if you use Q or SB then we should look at what is the practice these
runtimes offers for loading configmap/secret properties file during development
(if they have anything).
For camel-main then its standalone and we can make something Camel specific for
that (but this runtime is mostly used for quick prototyping via camel-jbang).
Instead of adding `config.xxx` as a key then I would recommend to keep it
naming consistent and let it be `camel.xxx` as that indiciate its Camel
specific and will not cause trouble for end users.
You can take a look at the existing properties component, as loading
secret/configmap files as .properties from a file-path during bootstrap does
not require kubernetes API / Jar so the code can be in camel-core. Then this
would be generic for all of Camel.
If all you want/need is camel-jbang only, then there is also possible to make
this jbang only, and have extra code in camel-jbang / camel-kamelet-main (yeah
its a bit of bad name but this is the main that runs camel jbang). This is
where all the jbang magic is located and this also allows to do some magic for
export.
> Recovering cloud native properties
> ----------------------------------
>
> Key: CAMEL-21036
> URL: https://issues.apache.org/jira/browse/CAMEL-21036
> Project: Camel
> Issue Type: New Feature
> Reporter: Pasquale Congiusti
> Assignee: Pasquale Congiusti
> Priority: Major
>
> When we run a Camel application on the cloud we may leverage the cloud native
> way of setting configuration. For example, when running on Kubernetes we may
> leverage the configmap and secret which are typically mounted as a key/value
> files.
> Given the following Secret:
> {code}
> apiVersion: v1
> data:
> org.acme.my-key: czNjcjN0
> kind: Secret
> ...
> {code}
> and the following Camel application Deployment volume mounted leveraging such
> a secret:
> {code}
> volumeMounts:
> - mountPath: /etc/camel/conf.d/_secret/my-properties
> name: my-properties
> readOnly: true
> {code}
> We may expect that at startup, the application scans a given directory (ie
> /etc/camel/conf.d/_configmaps|_secrets/) and add the parameter to the regular
> properties available to the context. From that moment onward, the application
> could leverage the properties placeholder, ie using {{org.acme.my-key}}.
> Ideally we should have a couple of properties to control the behavior, ie:
> cloud.config.scan=false (not sure if enable this by default)
> cloud.config.location=/etc/camel/conf.d
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
