Re: Parameter Contexts Expression Language scopes

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

Re: Parameter Contexts Expression Language scopes

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

Re: Parameter Contexts Expression Language scopes

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

Re: Parameter Contexts Expression Language scopes

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

Re: Parameter Contexts Expression Language scopes

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

Re: Parameter Contexts Expression Language scopes

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 >

Re: Parameter Contexts Expression Language scopes

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

Re: Parameter Contexts Expression Language scopes

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

Re: Parameter Contexts Expression Language scopes

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

Re: Parameter Contexts Expression Language scopes

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

Parameter Contexts Expression Language scopes

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