Shawn So that is one direction (being more restrictive). Another direction is to simply ditch the logic we have and allow changes and simply update the disconnected node when it rejoins. We have all kinds of super complex super duper awesome logic in there to help prevent users from getting into a bad state. What we have found is it was a lot of effort with minimal payoff. The simpler model is simply 'add the node to the cluster, make changes to ensure the flow matches, and move on'. The only failure case would be when connecting and there is data in a connection which no longer exists. We can make exception handling for that mode.
How does that sound for you? Thanks On Thu, Aug 26, 2021 at 7:51 AM Shawn Weeks <swe...@weeksconsulting.us> wrote: > > Hi, I know there have been a lot of improvements handling flow.xml.gz > differences between nodes if a node get’s disconnected or is down. I was > wondering if there is a way to prevent NiFi from allowing any flow changes if > all nodes are not up and available, both on the node that’s in a > “DISCONNECTED” state and for the remaining cluster nodes. I’m trying to > prevent the scenarios where a node ends up a disconnected state but still > allows changes making reconnections more challenging. > > > > Thanks > > Shawn
