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 >> >
