Georg Henzler wrote> Hi David,
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?
So even though the secrets directory doesn't contain any k8s-specifc
tokens, its format is still k8s-specific (I'm not aware of any other
configuration mechanism that uses a directory with flat files per
property... there are property files and some languages use yaml files,
but this mechanisms I have not seen elsewhere). So I think
org.apache.felix.configadmin.plugin.interpolation.k8sSecretsDir is the
correct way of specifying this (maybe we get
org.apache.felix.configadmin.plugin.interpolation.secretsPropertyFile
and others some time in the future)
While it might be true that only k8s uses this way atm, still the
implementation is independent and simply file system based. As this
configuration prop is tied to the "secret" keyword as a replacement, I
think renaming it to "secretsdir" makes sense. We might have
"secretspropertyfile" as you say later on.
And there is one more question: Do we really want to filter all property
sets for all PIDs? I suppose in reality often only < 5% of the
configuration data would actually contain placeholders. Would it be
worthwhile to introduce a property
org.apache.felix.configadmin.plugin.interpolation.pidRegex to limit the
PIDs that are transformed?
I don't think that's maintainable and creates an unnecessary
configuration overhead.
Each time you introduce usage of an interpolation in a configuration you
need to adjust
this central configuration as well.
I assume you're concerned about performance? Without numbers proving
this decreades performance significantly, I wouldn't do any upfront
optimization, especially not if it creates configuration burden.
Regards
Carsten
--
Carsten Ziegeler
Adobe Research Switzerland
[email protected]
