FWIW you can externalize connection strings and other similar properties into nifi.properties and have your processors references these environment variables through expression language. This way you can move the flow.xml.gz between two environments without changing anything after you setup the nifi.properties for each environment. The variable registry would just make this a much better user experience.
On Wed, Jan 27, 2016 at 12:07 PM, Joe Witt <[email protected]> wrote: > Matt, > > That is basically what we're talking about providing but it would be > transparent through the expression language capability. This approach > will make templates far more portable than they are today. > > Thanks > Joe > > On Wed, Jan 27, 2016 at 11:41 AM, Angry Duck Studio > <[email protected]> wrote: > > Why can't we just have a built-in persistent k-v store controller service > > that any processor can use? Could even modify the expression language to > > interact with it. Maybe something like ${props:<key>} where 'props' > refers > > to the built-in store. > > > > -Matt R > > > > On Wed, Jan 27, 2016 at 7:16 AM, Matt Gilman <[email protected]> > > wrote: > > > >> Simon, > >> > >> One idea that's been thrown around is adding a 'variable registry' [1] > >> where you could define variables at a group level that could be > referenced > >> by the encapsulated components. Additionally, this would help with the > >> portability of templates when needing to define different values for > >> different environments. > >> > >> Matt > >> > >> [1] https://cwiki.apache.org/confluence/display/NIFI/Variable+Registry > >> > >> On Wed, Jan 27, 2016 at 4:30 AM, Simon Ball <[email protected]> > wrote: > >> > >> > Other thoughts: > >> > > >> > This will have implications for broadcasting OnPropertyChanged events, > >> and > >> > potentially locking processors around the changes in properties held > by > >> the > >> > service. I’d love to hear if anyone can think of any other significant > >> land > >> > mines, or has had any thoughts on anything similar. > >> > > >> > Simon > >> > > >> > On 27 Jan 2016, at 09:26, Simon Ball <[email protected]<mailto: > >> > [email protected]>> wrote: > >> > > >> > One of the problems with complex flows is repetition of common > >> > configuration. Many people also want to be able to configure things > like > >> > connection strings into an environment specific location outside of > the > >> > Flow, and parameterise the flow. Things like the Kerberos|SSL|etc > Context > >> > service help in part with this, but the problem could be generalised. > >> > > >> > What do people think of the idea of a configuration provider > controller > >> > service, providing essentially the same concept as environment > variables, > >> > which holds essentially a key value store which processors can refer > to? > >> A > >> > simple way to refer to contents could be an extension on expression > >> > language providing a config(‘key’) function. > >> > > >> > What are your thoughts on this? Worth knocking up a quick prototype > >> > implementation (I’m happy to do so if there is community interest)? > >> > > >> > Simon > >> > > >> > > >> >
