[
https://issues.apache.org/jira/browse/CAMEL-21036?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17870966#comment-17870966
]
Pasquale Congiusti commented on CAMEL-21036:
--------------------------------------------
Thanks [~davsclaus], but IIUC, the above would work by explicitly defining in
the route the existence of a configmap/secret, ie
{{secret:my-sec/org.acme.my-key}} whilst I was thinking a transparent method in
order to use the property straight as it happens normally for the rest of
properties, ie {{org.acme.my-key}}. Or is it already working in this way?
> 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)
