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 <[email protected]>: > > 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.password" has value "${KEYSTORE_PASSWORD}" which then gets > the password from an environment variable. > > > >> On Mon, Oct 19, 2020 at 2:14 PM [email protected] <[email protected]> >> wrote: >> >> 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 hostname or the current JAVA path or ... or ... or on each >> node?! >> >> Mit freundlichen Grüßen / best regards >> Kay-Uwe Moosheimer >> >>>> Am 19.10.2020 um 20:00 schrieb Chad Zobrisky <[email protected]>: >>> >>> 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 parameter context, or >>> allowing a specific scope just for environment variables in the >>> expression language. >>> >>> I think giving access to environment variables actually allows more >>> portability between environments, eg dev, test, prod. Defining those once >>> and allowing for nifi to pull them in makes sense to me and I think is >>> common in container environments. >>> >>> Looking forward to discussing more and better approaches. >>> Chad >>> >>>> On Mon, Oct 19, 2020 at 1:46 PM Andy LoPresto <[email protected]> wrote: >>>> >>>> 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 this >>>> could introduce problems as parameters are designed for flexibility and >>>> portability, and moving from a system where a parameter was actually a >>>> pass-through to an environment variable would cause unexpected problems on >>>> the destination system. >>>> >>>> I think the pros and cons of this need to be clearly enumerated and >>>> discussed here. Thanks for bringing this up. >>>> >>>> >>>> Andy LoPresto >>>> [email protected] >>>> [email protected] >>>> He/Him >>>> PGP Fingerprint: 70EC B3E5 98A6 5A3F D3C4 BACE 3C6E F65B 2F7D EF69 >>>> >>>>>> On Oct 19, 2020, at 9:43 AM, Chad Zobrisky <[email protected]> wrote: >>>>> >>>>> 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_REGISTRY scope in the Expression Language, or a new scope for >>>>> references external to nifi? >>>>> >>>>> I think for refreshing the Parameter Context on those external changes, >>>> it >>>>> would require an edit/re-apply just as it does now, and would have to >>>> make >>>>> sure it is well documented. >>>>> >>>>> I'd be interested in creating a PR for this if the idea makes sense and >>>> is >>>>> acceptable. >>>>> >>>>> Thanks, >>>>> Chad >>>> >>>> >>
