Sven Van Kerrebroeck created NIFI-16317:
-------------------------------------------
Summary: GitLabFlowRegistryClient cannot commit local changes when
a newer flow version exists
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
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)
