[
https://issues.apache.org/jira/browse/NIFI-15694?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yuanhao Zhu updated NIFI-15694:
-------------------------------
Description:
For the past few Nifi version upgrades (2.5 - 2.6, 2.6 - 2.8), we have noticed
that sometimes a new release contains changes to the existing
processor/controller services attribute. And for a processor group under
version control, in this case the upgrade of nifi version will result in
changes like:
!image-2026-03-10-15-21-17-700.png!
But under the hood the value of these property stays actually the same. And
this brings a problem if you have multiple stages.
e.g. Assume we have 2 stages, dev and prod, they both have a processor group A
that is imported from the same flow in the same registry. And the version of
both flows is the latest version 16. Now I upgrade the dev nifi instance to the
next version, say 2.8.0, it introduces the changes mentioned above. So, we
commit those changes into nifi registry, which made the current version of
group A to be 17 in the registry now. And here comes the problem, if I upgrade
prod nifi instance also to 2.8.0, then the flow A on prod will be in status
conflicted, because though essentially on prod it also has the changes that's
introduced by nifi version upgrade, the version number of the flow definition
on prod is still 16 and nifi registry thinks this is a conflict. Also, here
sometimes you cannot roll back those local changes introduced by upgrade.
Currently, the only way that we think of to not have to delete the flow on prod
and reimport from registry is that we have a script that manually change such a
flow version number directly in the flow definition to the latest one.
And we think this is really not ideal, since it is not really a version
conflict, and we need to intervene manually.
was:
For the past few Nifi version upgrades (2.5 - 2.6, 2.6 - 2.8), we have noticed
that sometimes a new release contains changes to the existing
processor/controller services attribute. And for a processor group under
version control, in this case the upgrade of nifi version will result in
changes like:
!image-2026-03-10-15-21-17-700.png!
But under the hood the value of these property stays actually the same. And
this brings a problem if you have multiple stages.
e.g. Assume we have 2 stages, dev and prod, they both have a processor group A
that is imported from the same flow in the same registry. And the version of
both flows is the latest version 16. Now I upgrade the dev nifi instance to the
next version, say 2.8.0, it introduces the changes mentioned above. So, we
commit those changes into nifi registry, which made the current version of
group A to be 17 in the registry now. And here comes the problem, if I upgrade
prod nifi instance also to 2.8.0, then the flow A on prod will be in status
conflicted, because though essentially on prod it also has the changes that's
introduced by nifi version upgrade, the version number of the flow definition
on prod is still 16 and nifi registry thinks this is a conflict. Also here you
cannot roll back those changes introduced by upgrade
Currently, the only way that we think of to not have to delete the flow on prod
and reimport from registry is that we have a script that manually change such a
flow definition version number to the latest one.
And we think this is really not ideal, since it is not really a version
conflict, and we need to intervene manually.
> Processor group version issue with updated processor/controller service
> attribute from Nifi version
> ---------------------------------------------------------------------------------------------------
>
> Key: NIFI-15694
> URL: https://issues.apache.org/jira/browse/NIFI-15694
> Project: Apache NiFi
> Issue Type: Improvement
> Reporter: Yuanhao Zhu
> Priority: Major
> Attachments: image-2026-03-10-15-21-17-700.png
>
>
> For the past few Nifi version upgrades (2.5 - 2.6, 2.6 - 2.8), we have
> noticed that sometimes a new release contains changes to the existing
> processor/controller services attribute. And for a processor group under
> version control, in this case the upgrade of nifi version will result in
> changes like:
> !image-2026-03-10-15-21-17-700.png!
> But under the hood the value of these property stays actually the same. And
> this brings a problem if you have multiple stages.
> e.g. Assume we have 2 stages, dev and prod, they both have a processor group
> A that is imported from the same flow in the same registry. And the version
> of both flows is the latest version 16. Now I upgrade the dev nifi instance
> to the next version, say 2.8.0, it introduces the changes mentioned above.
> So, we commit those changes into nifi registry, which made the current
> version of group A to be 17 in the registry now. And here comes the problem,
> if I upgrade prod nifi instance also to 2.8.0, then the flow A on prod will
> be in status conflicted, because though essentially on prod it also has the
> changes that's introduced by nifi version upgrade, the version number of the
> flow definition on prod is still 16 and nifi registry thinks this is a
> conflict. Also, here sometimes you cannot roll back those local changes
> introduced by upgrade.
> Currently, the only way that we think of to not have to delete the flow on
> prod and reimport from registry is that we have a script that manually change
> such a flow version number directly in the flow definition to the latest one.
>
> And we think this is really not ideal, since it is not really a version
> conflict, and we need to intervene manually.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
