Hi Georg,
Thanks for the feedback!
On Mon, 29 Jul 2019 at 19:10, Georg Henzler <ghenz...@apache.org> wrote:
> Hi David,
>
> great to see this moving forward! Here are a few comments from my side:
>
> * I'm not sure if $[env:name] is the best syntax... I suppose you chose
> that over curly braces to not clash with potential other replacement
> mechanisms downstream. But $[] looks fairly similar to ${}, maybe
> something like %env:name%, %{env:name} or #{env:name} would make it
> visually clearer that it is not a ${} replacement.
>
I guess it would be an idea to make these configurable, however I'm not yet
fully convinced that it would really add much value. Is there a specific
thing you can't do or do you just want to make it look different?
> * It looks like there is no way to escape for the case $[env:name]
> should be treated as literal at the moment - e.g. something like
> \$[env:name] should be possible IMHO
>
Right yes, it should be possible to escape. Best thing would be to file a
bug for this. There is now a JIRA component for the plugin:
https://issues.apache.org/jira/projects/FELIX/versions/12345963
> * I think it's good to use the 'secret' prefix ala $[secret:name]
> generically, but we should also (at least potentially) allow for secret
> stores other than Kubernetes (as described in [1]). I think changing the
> property name org.apache.felix.configadmin.plugin.interpolation.dir [2]
> to org.apache.felix.configadmin.plugin.interpolation.k8sSecretsDir (or
> similar) would be good to clearly indicate the expected directory
> structure as referenced by this property.
>
The $[secret:name] lookup doesn't actually do anything that is k8s specific
in itself. K8s just puts the secrets in plain files: the name of the file
is the key and the entire content of the file is the secret value. That
pattern could also be used in a non-k8s context. Maybe we can rename the
property name to
'org.apache.felix.configadmin.plugin.interpolation.secretdir' or something
like that?
OTOH the plugin could definitely be extended to support other types of
secrets or config values coming out of files. I guess it would be good to
create JIRAs for these if you see the need.
Kind regards,
David
