Hi Mike, The menu items in the Version submenu are enabled/disabled based on the state of the versioned PG, which is an enum [1].
The menu options you are seeing, review local changes or revert, usually correspond to the “LOCALLY_MODIFIED_AND_STALE” state, which indicates that your NiFi instance is not on the latest version of the flow and also has local uncommitted changes. Before digging further into this issue, can you verify which version is saved to NiFi Registry and which version you are on in NiFi? Can you verify the state NiFi thinks the versioned PG is in? If you are not on the latest version, then this is actually correct behavior, the only option currently is to revert, upgrade to latest, and then introduce the changes again. For this, you may have to install the old version of the custom processor (you can have both installed simultaneously) in order to revert. If you are on the latest version that has been saved to NiFi Registry, then this sounds to me like a bug in determining the versioned PG state / flow diff and we’ll need to keep digging into the root cause. [1] https://github.com/apache/nifi/blob/master/nifi-api/src/main/java/org/apache/nifi/registry/flow/VersionedFlowState.java From: Mike Thomsen <[email protected]> Reply-To: "[email protected]" <[email protected]> Date: Friday, August 24, 2018 at 10:55 To: "[email protected]" <[email protected]> Subject: Re: Adding processor property broke ability to commit changes to the registry Kevin, 1. We added a new property definition in the Java code. Yes, the version number changes from 1.5.X to 1.6.X (these don't track NiFi releases FWIW). 2. We have ~ 3 layers of process groups. Only one of the inner PGs is versioned. The rest are all versioned at the parent level. When we added this new property, it was detected as a "local change" in one of those process groups that was not versioned on its own. The parent level one where the versioning is done only gives us two choices: review local changes or revert. Revert obviously doesn't work because it's a code change. The commit option is missing. It's like the registry doesn't know what to do since we added that new property. So yeah, it very much knows something changed, but it just won't let us commit. It doesn't even show that option. Thanks, Mike On Fri, Aug 24, 2018 at 10:00 AM Kevin Doran <[email protected]<mailto:[email protected]>> wrote: Hi Mike, I’ve never seen this before. I have a few questions for you to help me understand what could be going on: 1. When you say the custom processor got a new property, do you mean that the custom processor was modified to include a new property definition, and was recompiled/bundled and installed to overwrite the existing nar? If so, when the custom processor was updated, did the version number change? 2. Can you clarify what you mean by “It detects the new property at that level, but won't let us ‘commit local changes.’ ” – where has it detected local changes? In the parent PG? Does it give you the option to “show local changes” and if so what does it list? Does it give you the option to commit local changes, but that operation fails, or does it not give you the option at all (ie, it thinks it is in sync) If it’s not giving you the option to commit local changes because it can’t detect the change, one possible workaround off the top of my head would be to change something else (even just something like the position of the processor). Another possible workaround would be to version the processor so the old and new can be installed simultaneously and then change versions of the processor. If that wasn’t done it might be confusing the flow diff logic. Just a thought, happy to help dig into this with you more so we can file the appropriate JIRA to get it fixed so it doesn’t require special handling. Thanks, Kevin On Fri, Aug 24, 2018 at 9:23 AM Mike Thomsen <[email protected]<mailto:[email protected]>> wrote: We have a custom processor that got a new property. It's part of an embedded PG and the parent PG is version controlled. It detects the new property at that level, but won't let us "commit local changes." So we're stuck unable to commit. Has anyone seen this before or have any ideas on what is happening/work around? If not, I'll see if I can cleanly replicate and post a JIRA. Thanks, Mike
