markap14 commented on PR #6433: URL: https://github.com/apache/nifi/pull/6433#issuecomment-1255289595
So doing some testing I think the current approach will not work for embedded flows. In this PR, you make the VersionedFlowCoordinates now deprecate the Registry URL. This makes sense, since the URL is not a first-class citizen of the extension point. But it now uses the Registry ID in order to identify a flow. So if there is an inner Process Group that is versioned, and an outer Process Group that is versioned, the inner group is identified by this Registry ID. The problem, though, is that the Registry ID is specific to that nifi instance/cluster. If I then go to a different nifi cluster and create a Registry Client that points to the same registry, the Registry ID will not match, so that will create an issue. My recommendation would be: Instead of VersionedFlowCoordinates having a Registry ID, it would contain a 'Storage Location'. And that Storage Location would be a String. For the existing implementation that would be just the URL. And then, we'd update the FlowRegistryClient to have a new method: `boolean IsStorageLocationApplicable(String location)` or something of that nature. In this way, we can loop over all registry clients and find the one that allows for the storage location and use it to fetch the flow. In the case that there are multiple clients that indicate that the location is applicable, we can go through all clients. If it's able to find the flow, great. If not, go to the next one. Does that make sense & sound reasonable? -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
