I also see this as a good idea, if only for transportability. If the dev
environment is in a docker container and wants to use an environment
variable to set the context, but in production where the sensitive values
need more protection they can be set manually or in another way.
Chris Sampson's i
If parameters make it possible to use environment variables, then the system
can be configured in one place. You would not separate between expression
language and parameters.
It is also possible that an environment variable should be replaced by a
parameter or vice versa.
It makes sense to con
Sorry, the one list was meant to be...
a) system properties
b) environment variables
c) process-group variable registry
d) file-based variable registry
On Mon, Oct 19, 2020 at 4:35 PM Bryan Bende wrote:
>
> I think there is some confusion based on terminology...
>
> A given property has an expre
I think there is some confusion based on terminology...
A given property has an expression language scope defined, which can
be "flow file attributes" or "variable registry only". This was
created mostly for documentation purposes so that users could look at
a property in the docs and see "express
Being based primarily in Docker containers and having experience with both
Kubernetes (where secrets such as KESTORE_PASSWORD can be injected as
environment variables or files) and Docker Swarm (which only handles
secrets as environment variables), I'd have definitely been wanting this
before movin
Then I must have misunderstood it.
Thanks Bryan for clarification.
However, the idea of Chad makes sense for me.
Mit freundlichen Grüßen / best regards
Kay-Uwe Moosheimer
> Am 19.10.2020 um 20:35 schrieb Bryan Bende :
>
> Access to environment variables directly from expression language is
> n
Access to environment variables directly from expression language is
not being removed.
The discussion is about whether a parameter value should be able to
use expression language to reference an environment variable.
For example, processor property has #{keystore.password} -> parameter
"keystore
Chad,
So far I thought that only the NiFi variables are deprecated and access to
environment variables will still be possible.
If this is not the case, then I agree with you. It should definitely be
possible to access environment variables. Otherwise I can't imagine how to
refer to the hostnam
Andy,
Thanks for the response!
When I was thinking through this the deprecation of variables was
definitely on my mind but the fact that it already had direct access to
environment variables was the simplest path. I think it does make more
sense to add access to environment variables to the param
Hi Chad,
Parameters were introduced as a way to deprecate (NiFi) variables entirely. I’m
not sure that introducing a dependency between the two is a positive step
forward. I think there is a separate conversation to be had about allowing
parameters access to environment variables, but I think t
Hello,
I was configuring an SSL Context Controller Service today and had the
keystores and passwords passed into the container via environment
variables. I thought it would be nice to be able to reference these from
the parameter context. Maybe either giving Parameter Context values the
VARIABLE_R
11 matches
Mail list logo