Hi Deepak, So far, we have been honoring the following policy for what constitutes a change in version control:
- stopped/started does not count as a "local change" - enabled/disabled does count as a change, and that state is captured in the flow snapshot json version saved to registry. One reason for this is that some users want to setup CI/CD to deploy from Registry and automatically start a flow in the target NiFi. If there are components they don't want to start, the disabled state gives them a way to capture that configuration in the flow. Is there a reason you prefer disable over stop in your lower environment? I leave flows stopped in dev environments all the time and have never run into an issue, but of course, everyone's workflow and use case is slightly different, so I'm interested in hearing your perspective on this to see if we need to consider something more flexible. Cheers, Kevin On Dec 9, 2022 at 10:26:27, "Chirthani, Deepak Reddy" < c-deepakreddy.chirth...@charter.com> wrote: > Hey guys, > > So, once I fully develop and parameterize my nifi dataflow, let’s say in > dev environment, I enable the version control, import the flow in higher > environment and turn on the dataflow. In most of the cases both the flows > in lower and higher environments will be running. Let says dev nifi > connects to dev gcp pubsub and prod nifi connects to prod gcp pubsub. > However, in some cases, we do want to stop and disable the flow in lower > env. When I do that the registry is identifying that local changes are made > to the flow which is nothing but all the components are disabled. I don’t > want to keep the processors in stopped state on the canvas(registry do not > identify for stopping) but want to disable them. Any workaround for > registry not to identify local changes when flow is disabled? > > > > Thanks > > Deepak > > > > *[image: image005]* > > *Deepak Reddy* | Data Engineer > IT Centers of Excellence > 13736 Riverport Dr., Maryland Heights, MO 63043 > > > The contents of this e-mail message and > any attachments are intended solely for the > addressee(s) and may contain confidential > and/or legally privileged information. If you > are not the intended recipient of this message > or if this message has been addressed to you > in error, please immediately alert the sender > by reply e-mail and then delete this message > and any attachments. If you are not the > intended recipient, you are notified that > any use, dissemination, distribution, copying, > or storage of this message or any attachment > is strictly prohibited. >
