[
https://issues.apache.org/jira/browse/NIFI-15696?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pierre Villard updated NIFI-15696:
----------------------------------
Status: Patch Available (was: Open)
> 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
> Priority: Major
>
> 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)
