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
