[
https://issues.apache.org/jira/browse/NIFI-5029?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16782225#comment-16782225
]
George Knaggs edited comment on NIFI-5029 at 3/2/19 4:33 AM:
-------------------------------------------------------------
I am having similar issue, but in a simpler and perhaps more common use case.
It happens every time I try to promote changes to next environment with NiFi
Registry for a versioned flow with a nested version flow. It does not happen
if I import a copy of a that same versioned flow on the same environment as it
was created (dev).
I have a single instance of NiFi Registry that I use to promote changes between
my environments. I am using GIT Repository for flow persistence with NiFi
Registry. I am not using CLI, but the NiFi UI to import the versioned flow or
update version.
I am able to reproduce the issue if I import on my test env a versioned flow
with an nested version flow. I am also able to reproduce if I import on my
test env a versioned flow w/o any nested versioned flows, but later add one of
the nested flows to version control on my dev env, and then try to change the
version on test to the latest version of the flow now with a nested versioned
flow.
It took me a while to understand what was causing the issue and traced back the
problem only to a particular flow and only for versions after I added a nested
flow to version control.
My only option is to not allow nested version flows. From what I can tell, the
feature of allowing nested versioned flows is broken. I had hoped to
"componentize" my reusable sub flows under version control so when I fix a bug
or expand functionality in these sub flows, I could easily update the
"component" flow that was nested in other flows that use it by simply changing
the version. Now I will have to manually replicate changes until the issue is
fixed.
Please escalate the resolution of this bug as it was a very useful and powerful
feature.
was (Author: jorjnagz):
I am having similar issue, but in a simpler and perhaps more common use case.
It happens every time I try to promote changes to next environment with NiFi
Registry for a versioned flow that itself contains an embedded versioned group.
It does not happen if I import a copy of a that same versioned flow on the
same environment it was created (dev).
I have a single instance of NiFi Registry that I use to promote changes between
my environments. I am using GIT Repository for flow persistence with NiFi
Registry. I am not using CLI, but the NiFi UI to import the versioned flow or
update version.
I am able to reproduce the issue if I import on test env the versioned flow
with the embedded versioned group. I am also able to reproduce if I import on
test env a versioned flow w/o any embedded versioned groups, but later add an
embedded groups to version control on dev env, and then try to change the
version on test to the latest version of the flow now with an embedded
versioned group.
It took me a while to understand what was causing the issue and traced back the
problem only to a particular flow and only for versions after I added embedded
groups to version control.
My only option is to not use embedded version groups. This is a completely
broken feature and removes the advantage of version control for sub flows. I
had hoped to have componitize my reusable sub flows under version control so
when I fix a bug or expand functionality in these flows, I could easily update
of the component flow in every full flows that uses it by simply changing the
version. Please escalate the resolution of this bug in order to use this
feature.
> CLI - Handling of embedded versioned process groups during export/import
> ------------------------------------------------------------------------
>
> Key: NIFI-5029
> URL: https://issues.apache.org/jira/browse/NIFI-5029
> Project: Apache NiFi
> Issue Type: Improvement
> Components: Flow Versioning, SDLC, Tools and Build
> Reporter: Pierre Villard
> Priority: Major
>
> I'm in a situation where, in my dev environment, I have a versioned process
> group A in bucket bA containing an embedded process group B from bucket bB.
> Both A and B are versioned in the NiFi Registry of my dev environment.
> I'm using the CLI to export both A and B from my dev Registry, and then
> importing A and B in my prod Registry. The issue is that in the json
> representing A, there is a reference to B containing the url of the dev
> Registry, the bucket ID and the workflow ID representing B.
> To import B in my prod registry, I first created a bucket bB and a workflow
> B. New UUIDs have been generated for both in the prod registry. Then I did
> the import of the JSON representing B.
> Now I manually update the JSON representing A to set the UUIDs related to B
> with the new values of my prod registry. Then I created a bucket and a
> workflow for A in my prod registry, and did the import.
> Problem occurs when I try to import the process group A in my prod NiFi.
> It'll fail with an error looking like this:
> {code:java}
> #> nifi pg-change-version -fv 2 -pgid &1 -u http://localhost:8080
> > Using a positional back-reference for 'A'
> ERROR: Error executing command 'pg-change-version' : Error updating version
> control information: The Flow Registry with ID
> 56a49113-0162-1000-0a7e-4959d312d445 reports that no Flow exists with Bucket
> 9d87ccc4-7084-4069-850a-7704135ea9e9, Flow
> 7e47aeba-4908-41a6-88d7-e6deb1abef98, Version 2{code}
> I guess there are multiple ways of handling it. It could be on the CLI side
> or on the Registry side (could be related to NIFIREG-148).
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
