[
https://issues.apache.org/jira/browse/CAMEL-21036?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17871931#comment-17871931
]
Pasquale Congiusti commented on CAMEL-21036:
--------------------------------------------
[~claudio4j] I think this is slightly different. The goal is to load
configuration without knowing the name of the secrets/configmaps ahead of time.
> 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
> Fix For: 4.8.0
>
>
> 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)
