Pierre Villard created NIFI-15696:
-------------------------------------
Summary: Add Rebase operation for versioned process groups
Key: NIFI-15696
URL: https://issues.apache.org/jira/browse/NIFI-15696
Project: Apache NiFi
Issue Type: New Feature
Components: Flow Versioning
Reporter: Pierre Villard
Assignee: Pierre Villard
When a versioned process group is at version N with local modifications (state
{*}LOCALLY_MODIFIED_AND_STALE{*}), upgrading to a newer version requires
reverting all local changes first, then changing version, then manually
re-applying every customization. This is error-prone, causes unnecessary
downtime, and discourages users from upgrading.
This change adds a "Rebase" operation that upgrades a versioned process group
to a newer registry version while automatically preserving compatible local
changes — analogous to git rebase.
{*}How it works{*}:
The rebase operation has two phases:
# Analysis (read-only): Computes a three-way diff between the local flow, the
base registry version (N), and the target registry version. Each local change
is classified as Compatible (will be preserved), Conflicting (same field
changed both locally and upstream to different values), or Unsupported (change
type not yet supported by a rebase handler). Rebase is only allowed when all
local changes are compatible.
# Execution: Deep-clones the target version snapshot, overlays compatible
local changes onto it to produce a merged snapshot, then synchronizes the
process group to the merged snapshot using the existing FlowUpdateResource
async infrastructure. The VCI is set to the clean target version so that
subsequent state checks correctly report LOCALLY_MODIFIED.
Supported change types (for this first iteration, this will evolve over time):
* POSITION_CHANGED, SIZE_CHANGED, BENDPOINTS_CHANGED — cosmetic, always
compatible (local wins)
* PROPERTY_CHANGED, PROPERTY_ADDED — compatible unless upstream changed the
same property on the same component to a different value (convergent changes
where both sides set the same value are accepted)
* COMMENTS_CHANGED — compatible unless upstream also changed comments on the
same component
Unsupported change types (examples: COMPONENT_ADDED, COMPONENT_REMOVED) block
the rebase with a clear message. The handler architecture is extensible —
adding support for a new change type requires only implementing a single
RebaseHandler class.
We follow a similar approach as what already exists for the new API endpoints:
* GET /versions/rebase-analysis/process-groups/\{id}?targetVersion=\{version}
returns the three-way analysis
* POST /versions/rebase-requests/process-groups/\{id}
initiates async rebase execution
* GET/DELETE /versions/rebase-requests/\{id}
polling and cleanup (reuses FlowUpdateResource)
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
