Mark/Kevin, I think this comment on NIFI-5448 is related to what I was seeing:
https://issues.apache.org/jira/browse/NIFI-5448?focusedCommentId=16612166&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-16612166 One take away from this is that the version conflict strategy should, ideally, be able to figure out if a built-in property has had its value changed from the default and ignore it if it hasn't in such cases. On Fri, Aug 24, 2018 at 11:43 AM Kevin Doran <[email protected]> wrote: > 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]> 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]> > 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 > >
