NIFI-4921 better support for promoting NiFi processor parameters between
dev and prod environments
On Thu, Mar 1, 2018 at 11:43 AM, Bryan Bende <bbe...@gmail.com> wrote:
> Glad you are having success with NiFi + NiFi Registry!
> You brought up an interesting point about the concurrent tasks...
> I think we may want to consider making the concurrent tasks work
> similar to variables, in that we capture the concurrent tasks that the
> flow was developed with and would use it initially, but then if you
> have modified this value in the target environment it would not
> trigger a local change and would be retained across upgrades so that
> you don't have to reset it.
> For now you could probably always leave the versioned flow with the
> lower value of 2, then once you are in prod you bump it to 4 until the
> next upgrade is available, you then revert the local changes, do the
> upgrade, and put it back to 4, but its not ideal because it shows a
> local change the entire time.
> I don't think there is much you can do differently right now, but I
> think this is a valid case to create a JIRA for.
> On Thu, Mar 1, 2018 at 11:29 AM, Boris Tyukin <bo...@boristyukin.com>
> > Hello NiFi community,
> > started using NiFi recently and fell in love with it! We run 1.6 NiFi
> > with new NiFi registry and I am trying to figure out how to promote NiFi
> > flow, created in VM environment to our cluster.
> > One of the things is "Concurrent Tasks" processor parameter. I bump it
> to 2
> > or 4 for some processors in my flow, when I develop / test it in VM.
> > Then we deploy this flow to a beefy cluster node (with 48 cores) and
> want to
> > change concurrency to let's say 8 or 10 or 12 for some processors.
> > Then I work on a new version/make some changes in my VM, and need to be
> > shy with concurrency so set it back to 2 or 4.
> > Then the story repeats...
> > Is there a better way than to manually set this parameter? I do not
> > I can use a variable there and have to type the actual number of tasks.
> > Thanks
> > Boris