[
https://issues.apache.org/jira/browse/NIFI-15341?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18045915#comment-18045915
]
David Handermann commented on NIFI-15341:
-----------------------------------------
Thanks for continuing the discussion [~pgrey] and [~jgresock].
One of the main differences between the current property migration support and
this proposal is handling of external property names. The current
implementation is designed to handle upgrading the flow configuration based on
the persisted version. Supporting translation from an external input raises a
different set of questions.
>From that perspective, calling the migration lifecycle methods while loading
>the flow configuration is one thing, but calling them for every new external
>request is another. That is not to say it can't be done, but it highlights an
>additional layer involved.
One option that comes to mind is making this easier to handle as a client-side
responsibility. For example, if the goal is limited to handling simple
renaming, providing a project-maintained mapping that could be consumed
programmatically could be one way to support this type of migration on the
client side. It could be a simple two-column CSV structure with old and new
property names, which could be the basis for substitution in a client-side
request. This would be decoupled from the migration lifecycle methods, would it
would also provide a clearer contract in terms of what is supported, and what
is not, for handling client-side property renaming. Maintaining a separate
mapping would take a little work initially, but once completed, it should not
be hard to maintain. It may even make sense to have this as a page in
Confluence, versus something in the repository itself.
Having a multi-pass flow migration might be an option, although it raises
complexity and performance questions depending on the size of the flow
configuration. If you have an example approach in a branch [~jgresock], that
could be helpful for evaluation.
Thoughts on making this easier to support from a client-side perspective?
It is important to keep in mind that these migration methods are targets for
removal in a future major version release, which may be another reason to have
a client-side solution as well.
> External Controller Service resolution can break with property migration
> ------------------------------------------------------------------------
>
> Key: NIFI-15341
> URL: https://issues.apache.org/jira/browse/NIFI-15341
> Project: Apache NiFi
> Issue Type: Bug
> Components: Core Framework
> Affects Versions: 2.7.1
> Reporter: Joe Gresock
> Assignee: Joe Gresock
> Priority: Minor
> Attachments: CS_Resolution.json
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> When importing or replacing a Process Group, External Controller Services can
> fail to resolve if a component property was renamed between the versioned
> flow and the currently installed bundle using property migration.
> To reproduce in 2.4.0 or later, download attached JSON file representing a
> Process Group Replace request. Then log into NiFi and copy the Bearer token.
> Then create a new blank process group in NiFi and copy its identifier for
> below.
> Next, create a new StandardRestrictedSSLContextService at the root canvas and
> name it "SSL Context Service".
> {code:java}
> BEARER_TOKEN=<paste bearer token>
> PG_ID=<pg id>
> curl -k -vv -X POST
> https://localhost:8443/nifi-api/process-groups/$PG_ID/replace-requests -H
> "Content-Type: application/json" -H "Authorization: Bearer $BEARER_TOKEN" -d
> @CS_Resolution.json
> {code}
> Observe that the SSL Context Service property in the MongoDBControllerService
> now references a UUID instead of the "SSL Context Service" service.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
