Following up on this, it looks like the history entry is maintained in local state even if the process group is removed. So, I can import the process again, stop the server, and change the history file with a text editor to maintain state. This seems to work. I'm trying to figure out a way to do this automatically, unfortunately it doesn't look like there's a PUT option for state.
Thanks, Dave -----Original Message----- From: David Gallagher <dgallag...@cleverdevices.com> Sent: Thursday, February 13, 2020 3:32 PM To: firstname.lastname@example.org Subject: RE: NiFi 1.8.0 to 1.11.1 upgrade issue Yes, recreating the PG works but as you say, my concern is loss of state. I need to maintain the state of the database query tasks to prevent myself from getting a full reload. Is there a way to preserve the state? -----Original Message----- From: Bryan Bende <bbe...@gmail.com> Sent: Thursday, February 13, 2020 12:54 PM To: email@example.com Subject: Re: NiFi 1.8.0 to 1.11.1 upgrade issue I'm not sure if this option works for you, but in 1.10.0 there was a force-commit option added, I think it just labeled as Commit but basically you should be able to commit even when there are newer versions in the registry. So if the new version in registry doesn't have any real changes other than changing versions from 1.8 to 1.11, then technically the flow in QA is the same and you could just force-commit on top of whatever is in registry. If the newer version in the registry really does have changes you need, then I think you would have to import the flow from scratch to get out of this case, and delete the original PG, not sure if this causes problems to possibly lose the state from some processors. On Thu, Feb 13, 2020 at 12:50 PM Matt Burgess <mattyb...@apache.org> wrote: > > Looks like this change was made in 1.9.0: > https://nam05.safelinks.protection.outlook.com/?url=https%3A%2F%2Fissu > es.apache.org%2Fjira%2Fbrowse%2FNIFI-5812&data=02%7C01%7Cdgallaghe > r%40cleverdevices.com%7C2476bd845b55445ade8608d7b0adba41%7Cc24ec497266 > d4560bcda1d93096d9d18%7C0%7C0%7C637172132511735269&sdata=Iy9%2FN5O > cRxfE7E78NOFWkxj6xX3uGKX7fseKPvFSqI0%3D&reserved=0 > > On Thu, Feb 13, 2020 at 11:55 AM David Gallagher > <dgallag...@cleverdevices.com> wrote: > > > > @Bryan Bende, to add to this it looks like 'All' was an option in 1.8.0 but > > is no longer an option in 1.11.1. This is why it can't be reverted, it > > seems. > > > > Thanks, > > > > Dave > > > > -----Original Message----- > > From: Bryan Bende <bbe...@gmail.com> > > Sent: Thursday, February 13, 2020 10:24 AM > > To: firstname.lastname@example.org > > Subject: Re: NiFi 1.8.0 to 1.11.1 upgrade issue > > > > Ok so your QA environment has been upgraded to 1.11.1 and there is an > > existing flow that is now in a conflict state because it says there are > > local changes for the new properties, but also says a new version is > > available from what was committed to registry from the dev environment? > > > > Can you provider the exact message from Show Local Changes? > > > > Execution Node is actually not a property, it is part of the scheduling of > > the processor. It looks like QueryDatabaseTable was changed somewhere in > > there to have @PrimaryNodeOnly which means it can only be scheduled on the > > primary node, and maybe you previously had it schedule on all nodes? > > > > On Thu, Feb 13, 2020 at 9:57 AM David Gallagher > > <dgallag...@cleverdevices.com> wrote: > > > > > > Hi Bryan - > > > > > > The new version of the flow came from a development environment. Thinking > > > back on it, I upgraded that development environment from 1.8 -> 1.11.1 > > > first and committed the change described to the 0.2.0 registry. I then > > > upgraded the registry to 0.5.0, made another change, and committed that > > > so I could get a new version of the flow with 0.5 metadata. That flow > > > version is what I'm trying to import into the QA environment below. > > > > > > Thanks, > > > > > > Dave > > > > > > -----Original Message----- > > > From: Bryan Bende <bbe...@gmail.com> > > > Sent: Thursday, February 13, 2020 9:20 AM > > > To: email@example.com > > > Subject: Re: NiFi 1.8.0 to 1.11.1 upgrade issue > > > > > > Hello, > > > > > > Can you elaborate on what step 3 means? Where did this new version come > > > from that was imported to registry? > > > > > > -Bryan > > > > > > On Thu, Feb 13, 2020 at 9:11 AM David Gallagher > > > <dgallag...@cleverdevices.com> wrote: > > > > > > > > Hi – I’m currently converting our flows from 1.8.0 to 1.11.1, with a > > > > parallel upgrade from registry 0.2.0 to registry 0.5.0. Currently stuck > > > > due to this set of steps: > > > > > > > > > > > > > > > > Upgraded registry from 0.2.0 to 0.5.0 Upgraded NiFi from 1.8.0 > > > > to > > > > 1.11.1 Imported a new version of a flow to the 0.5.0 registry > > > > > > > > > > > > > > > > It looks like the QueryDatabaseTable processor gained some new > > > > properties (‘Execution Mode’ now has ALL and PRIMARY options). So, the > > > > flow is stuck because both local changes and a new version of the flow > > > > (in the registry) are available. I’ve tried reverting local changes, > > > > but the changes are just put right back. If I accept the changes (i.e. > > > > commit local), I’m getting an error warning saying that available > > > > upgrades will be ignored. Is there a way out of this one? Barring that, > > > > is the preferred method to upgrade NiFi first, commit changes to the > > > > registry, and then upgrade the registry? > > > > > > > > > > > > > > > > Thanks, > > > > > > > > > > > > > > > > Dave