Mark Payne created NIFI-15988:
---------------------------------
Summary: 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
Fix For: nifi-api-2.9.0
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)
