We currently have a solid dev / prod environment and when ready we import the template from dev in to prod. We also have updated central processors that can't be replaced by a template with rest calls.
But in general NIFI 1 is a massive upgrade to U/I, and this feature and user policies from a operational perspective are why I'm pushing for nifi 1 in my environment, but major drawback is code review for custom code and resources to do so. On Wed, Apr 12, 2017 at 1:19 PM James McMahon <jsmcmah...@gmail.com> wrote: > Okay thanks Joe. And I apologize: it seems you have mentioned that before. > > On Wed, Apr 12, 2017 at 1:09 PM, Joe Witt <joe.w...@gmail.com> wrote: > >> Hello >> >> This has been addressed in NiFi 1.x. You can have multiple writers to >> various things in parallel and it handles it nicely. >> >> Thanks >> Joe >> >> On Wed, Apr 12, 2017 at 12:03 PM, James McMahon <jsmcmah...@gmail.com> >> wrote: >> > We have multiple people working is separate distinct processor groups >> under >> > a common NiFi instance. As would be expected, they are often making >> changes >> > to their processor group workflows concurrently. >> > >> > There are long periods of time where Betty loses any attempted changes >> > including reposition of processors, configuration changes, etc because >> Timmy >> > has made changes in his processor group. The system prompts Betty with a >> > synchronization alert message, and when she then closes that pop up >> alert >> > her changes are gone. The message posted to Betty in such circumstances >> is: >> > >> > "This NiFi instance has been updated by 'SMITH TIMMY. Please refresh to >> > synchronize the view." >> > >> > Two related questions: >> > 1. why are the changes in a Processor Group impacting the other when >> there >> > are no dependencies other than the services each may use? >> > 2. Is it possible to avoid this with a configuration change? >> > 3. does Timmy have to be fired because he keeps getting in Betty's way? >> > >> > -Jim (yes, Timmy) >> > >
