[
https://issues.apache.org/jira/browse/CAMEL-21036?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pasquale Congiusti updated CAMEL-21036:
---------------------------------------
Description:
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
was:
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
configmap:
{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
> 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
> 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)
