Peter, I feel like this came up before, and unfortunately I'm not sure there is currently a solution.
I think ultimately there needs to be some kind of force upgrade so you can ignore the local changes and take whatever is available. The only thing I can think of, but haven't tried, is if you had upgraded the PG in the second instance before upgrading NiFi itself, it would bring in the new properties that are not valid in that version and the processor would show as invalid, then upgrade NiFi and it would be valid again. -Bryan On Thu, Nov 29, 2018 at 3:13 PM Peter Wicks (pwicks) <pwi...@micron.com> wrote: > > Ran into a NiFi Registry issue while upgrading our instances to NiFi 1.8.0. > ExecuteSQL had a number of new properties added to it in 1.8.0, so after > upgrading our, our versioned processor groups show as having local changes, > which is good. We went ahead and checked the changes into the registry. > > > > Enter the second instance... we upgraded a second instance. It also see's > local changes, but now the processor group is in conflict, because we have > local (identical) changes, and we have a newer version checked in. If you try > to revert the local changes so you can sync things up... you can't, because > these are properties on the Processor, and the default values automatically > come back. So our second processor group is in conflict and we haven't found > a way to bring it back in sync without deleting it and re loading it from the > registry. Help would be appreciated. > > > > Thanks, > > Peter
