[
https://issues.apache.org/jira/browse/NIFI-15341?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18045627#comment-18045627
]
Paul Grey commented on NIFI-15341:
----------------------------------
Hey [~exceptionfactory]
Having followed along in the associated PR, it seems reasonable for you to want
to take a step back and consider options to mitigate this issue.
The component property naming convention in NiFi 1 (which carried over to
initial versions of NiFi 2) was evolutionary and a bit haphazard. I've
personally been bitten by discrepancies between display name and API name of
component properties, so the goal of standardizing and simplifying in that area
makes sense. It is also true that there have been migration-related issues
recently, possibly with more to come.
The whole concept of a `migrateProperties()` API seems like a good idea,
because the alternative would be to break backward compatibility whenever a
property name changes. With this API in place, flow definitions created with
earlier versions of NiFi can work seamlessly in newer versions of NiFi. I can
imagine that there are a lot of flow definitions in the user base that benefit
from this solution, both loose JSON content and committed content in user NiFi
Registry instances.
It seems like the goal in this JIRA is to extend the `migrateProperties()`
facility to cover the additional use case of `externalControllerService`
references. The NiFi UI, when exporting a process group flow definition,
offers the "Download Flow Definition / Without External Services / With
External Services" option. So this seems to be more than just an edge case.
In the same way that `migrateProperties()` was accommodated in the context of
`nifi-framework`, maybe this targeted fix can also somehow be accommodated.
You raise reasonable concerns about module dependencies, and about complexity
in the framework. That being said, it does seem like there should be some
solution that will address this oversight in the property migration effort.
Look forward to discussing further and brainstorming solutions!
> 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: 10m
> 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)
