[
https://issues.apache.org/jira/browse/NIFI-16317?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sven Van Kerrebroeck updated NIFI-16317:
----------------------------------------
Summary: Upgrade-generated component migrations block flow deployments in
multi-environment setups (was: GitLabFlowRegistryClient cannot commit local
changes when a newer flow version exists)
> Upgrade-generated component migrations block flow deployments in
> multi-environment setups
> -----------------------------------------------------------------------------------------
>
> Key: NIFI-16317
> URL: https://issues.apache.org/jira/browse/NIFI-16317
> Project: Apache NiFi
> Issue Type: Bug
> Affects Versions: 2.11.0
> Environment: OS: RedHat (RedHat 8.10)
> Kernel: 4.18.0
> CPUs: 4 (Intel(R) Xeon(R) Gold 6348 CPU @ 2.60GHz)
> GitLab integration via the GitLabFlowRegistryClient
> Reporter: Sven Van Kerrebroeck
> Priority: Critical
>
> After upgrading NiFi from 2.9.0 to 2.11.0, some controller services (e.g.
> {{{}AvroSchemaRegistry{}}}) are automatically migrated and appear as local
> changes in versioned process groups.
> This is ok on our development environment, but when you upgrade the next
> environments (like staging or production), this is a problem.
> These upgrade-generated local changes cannot be reverted, because after the
> revert the component migration is applied again. So these changes stay in
> place.
> As long as there are local changes, you cannot deploy new versions of the
> flows.
> So basically you are stuck.
> As a workaround, we tried to commit the local changes directly on the higher
> environments. NiFi correctly detects that a newer flow version is available
> in the registry and asks for confirmation:
> {quote}“Committing will ignore available upgrades and commit local changes as
> the next version. Are you sure you want to proceed?”
> {quote}
> After confirming {*}Yes{*}, and proceding with the commit, this still fails:
> {quote}“Failed to register flow with Flow Registry due to The file has
> changed since you started editing it: ..../.... .json”
> {quote}
> This makes the confirmation misleading: NiFi explicitly allows committing
> local changes while ignoring available upgrades, but the
> {{GitLabFlowRegistryClient}} subsequently rejects the operation because the
> file was modified.
> This leaves you in a completely blocked state in a multi-environment setup:
> upgrade-generated local changes can leave an environment unable to:
> * revert the local changes,
> * upgrade to the newer flow version, or
> * commit the local changes as a new version.
> This effectively blocksany further flow deployments.
>
> Only option is to delete all flows and deploy them from scratch from the repo
> (which is a real pain, because that also means that you loose state for some
> processors).
> So basically there are 2 problems:
> * local changes that are being generated automatically on upgrade, should
> not be real "local changes", or you should be able to revert them (make the
> flow invalid) and then deploy a new version of the flow.
> * when trying to commit a flow when there is already a newer version in the
> repo, and clearly accepting the alert, should allow to actually commit.
>
> This seems to be related also to issue: NIFI-15694 (which was logged in
> march and for which a colleague of mine has provided a possible PR)
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
