You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@nifi.apache.org by David Gallagher <dg...@CleverDevices.com> on 2020/02/13 14:11:01 UTC
NiFi 1.8.0 to 1.11.1 upgrade issue
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:
1. Upgraded registry from 0.2.0 to 0.5.0
2. Upgraded NiFi from 1.8.0 to 1.11.1
3. 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
RE: NiFi 1.8.0 to 1.11.1 upgrade issue
Posted by David Gallagher <dg...@CleverDevices.com>.
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 <dg...@CleverDevices.com>
Sent: Thursday, February 13, 2020 3:32 PM
To: users@nifi.apache.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 <bb...@gmail.com>
Sent: Thursday, February 13, 2020 12:54 PM
To: users@nifi.apache.org
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 <ma...@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
> <dg...@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 <bb...@gmail.com>
> > Sent: Thursday, February 13, 2020 10:24 AM
> > To: users@nifi.apache.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 <dg...@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 <bb...@gmail.com>
> > > Sent: Thursday, February 13, 2020 9:20 AM
> > > To: users@nifi.apache.org
> > > 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 <dg...@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
RE: NiFi 1.8.0 to 1.11.1 upgrade issue
Posted by David Gallagher <dg...@CleverDevices.com>.
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 <bb...@gmail.com>
Sent: Thursday, February 13, 2020 12:54 PM
To: users@nifi.apache.org
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 <ma...@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
> <dg...@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 <bb...@gmail.com>
> > Sent: Thursday, February 13, 2020 10:24 AM
> > To: users@nifi.apache.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 <dg...@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 <bb...@gmail.com>
> > > Sent: Thursday, February 13, 2020 9:20 AM
> > > To: users@nifi.apache.org
> > > 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 <dg...@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
Re: NiFi 1.8.0 to 1.11.1 upgrade issue
Posted by Bryan Bende <bb...@gmail.com>.
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 <ma...@apache.org> wrote:
>
> Looks like this change was made in 1.9.0:
> https://issues.apache.org/jira/browse/NIFI-5812
>
> On Thu, Feb 13, 2020 at 11:55 AM David Gallagher
> <dg...@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 <bb...@gmail.com>
> > Sent: Thursday, February 13, 2020 10:24 AM
> > To: users@nifi.apache.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 <dg...@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 <bb...@gmail.com>
> > > Sent: Thursday, February 13, 2020 9:20 AM
> > > To: users@nifi.apache.org
> > > 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 <dg...@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
Re: NiFi 1.8.0 to 1.11.1 upgrade issue
Posted by Matt Burgess <ma...@apache.org>.
Looks like this change was made in 1.9.0:
https://issues.apache.org/jira/browse/NIFI-5812
On Thu, Feb 13, 2020 at 11:55 AM David Gallagher
<dg...@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 <bb...@gmail.com>
> Sent: Thursday, February 13, 2020 10:24 AM
> To: users@nifi.apache.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 <dg...@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 <bb...@gmail.com>
> > Sent: Thursday, February 13, 2020 9:20 AM
> > To: users@nifi.apache.org
> > 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 <dg...@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
RE: NiFi 1.8.0 to 1.11.1 upgrade issue
Posted by David Gallagher <dg...@CleverDevices.com>.
@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 <bb...@gmail.com>
Sent: Thursday, February 13, 2020 10:24 AM
To: users@nifi.apache.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 <dg...@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 <bb...@gmail.com>
> Sent: Thursday, February 13, 2020 9:20 AM
> To: users@nifi.apache.org
> 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 <dg...@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
RE: NiFi 1.8.0 to 1.11.1 upgrade issue
Posted by David Gallagher <dg...@CleverDevices.com>.
Hi Bryan - this is the message I see when I upgrade to 1.11:
Execution Mode Changed From 'ALL' to 'PRIMARY'
-----Original Message-----
From: Bryan Bende <bb...@gmail.com>
Sent: Thursday, February 13, 2020 10:24 AM
To: users@nifi.apache.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 <dg...@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 <bb...@gmail.com>
> Sent: Thursday, February 13, 2020 9:20 AM
> To: users@nifi.apache.org
> 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 <dg...@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
Re: NiFi 1.8.0 to 1.11.1 upgrade issue
Posted by Bryan Bende <bb...@gmail.com>.
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
<dg...@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 <bb...@gmail.com>
> Sent: Thursday, February 13, 2020 9:20 AM
> To: users@nifi.apache.org
> 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 <dg...@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
RE: NiFi 1.8.0 to 1.11.1 upgrade issue
Posted by David Gallagher <dg...@CleverDevices.com>.
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 <bb...@gmail.com>
Sent: Thursday, February 13, 2020 9:20 AM
To: users@nifi.apache.org
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 <dg...@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
Re: NiFi 1.8.0 to 1.11.1 upgrade issue
Posted by Bryan Bende <bb...@gmail.com>.
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
<dg...@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