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
> >
> >
>

Reply via email to