[
https://issues.apache.org/jira/browse/NIFI-15988?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mark Payne updated NIFI-15988:
------------------------------
Status: Patch Available (was: Open)
> Split `MigratableConnector` into two separate migration phases
> --------------------------------------------------------------
>
> Key: NIFI-15988
> URL: https://issues.apache.org/jira/browse/NIFI-15988
> Project: Apache NiFi
> Issue Type: Improvement
> Components: Core Framework, NiFi API
> Reporter: Mark Payne
> Assignee: Mark Payne
> Priority: Major
> Fix For: nifi-api-2.9.0
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> In NIP-29 we introduced the ability to migrate an existing Process Group's
> assets, configuration, and state into a Connector.
> There was, however, a shortcoming in the interface that provided this
> capability. It is an opt-in style interface named `MigratableConnector` with
> two methods:
> {code}
> boolean isMigrationSupported(ConnectorMigrationContext context);
> void migrate(ConnectorMigrationContext context) throws FlowUpdateException;
> {code}
> The intent of `migrate` was to allow it to update the flow as appropriate to
> mirror the configuration of the provided VersionedProcessGroup (available via
> ConnectorMigrationContext).
> The shortcoming is that while this will update the flow, it does NOT properly
> update the Connector's configuration. So after migrating, if a user were to
> configure the Connector, they would not see the changes. And upon restart
> we'd have lost those changes unless we built something into the framework to
> explicitly handle this.
> So we should instead break up the `migrate` method into a two-phase approach:
> {code}
> void migrateConfiguration(ConnectorMigrationContext context) throws
> FlowUpdateException;
> void migrateState(ConnectorMigrationContext context) throws
> FlowUpdateException;
> {code}
> Where we introduce new methods to `ConnectorMigrationContext`:
> {code}
> void setProperties(String stepName, Map<String, String> propertyValues);
> void replaceProperties(String stepName, Map<String, String> propertyValues);
> void setComponentState(String managedComponentId, VersionedComponentState
> state);
> {code}
> Both `setProperties` and `replaceProperties` would be usable during Phase 1
> (`migrateConfiguration`). Then the framework will be responsible for calling
> the existing `applyUpdate` method, which updates the Connector's flow. This
> is much more consistent with the existing API.
> Once the flow has been updated and all necessary components created, the
> framework will call `migrateState`, and the Connector will be able to call
> `setComponentState` as appropriate to define the state for each component. It
> is still up to the framework to actually apply the state via `StateManager`.
> This brings the migration API much more inline with the typical operating
> mode for Connectors and ensures that we apply and persist the configuration
> appropriately.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
