You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@nifi.apache.org by "Michael W Moser (Jira)" <ji...@apache.org> on 2023/11/20 21:18:00 UTC
[jira] [Updated] (NIFI-12394) Versioned flow with multiple components referencing same controller service will only have 1 valid component after import
[ https://issues.apache.org/jira/browse/NIFI-12394?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Michael W Moser updated NIFI-12394:
-----------------------------------
Description:
I built a Process Group containing one StandardRestrictedSSLContextService that is referenced by an InvokeHTTP and a ListenHTTP processor. I downloaded that Process Group as a flow definition with external services. I also versioned that Process Group in NiFi Registry.
Inside the flow definition, I see the StandardRestrictedSSLContextService with "identifier":"d7d70b6c-abe4-3564-a219-b289cb7f25d2" and both InvokeHTTP and ListenHTTP referencing that same UUID.
When I create a new Process Group using either the downloaded flow definition or the NiFi Registry flow, the StandardRestrictedSSLContextService is invalid as expected and it has a new UUID as expected. I enter the keystore and truststore passwords and enable the service. Only one processor references the new StandardRestrictedSSLContextService. The other processor is still invalid because it references the old UUID d7d70b6c-abe4-3564-a219-b289cb7f25d2 which does not exist.
edit: I tried this using a controller service that does not have sensitive properties, and did not have this problem, so it could be related to sensitive properties.
was:
I built a Process Group containing one StandardRestrictedSSLContextService that is referenced by an InvokeHTTP and a ListenHTTP processor. I downloaded that Process Group as a flow definition with external services. I also versioned that Process Group in NiFi Registry.
Inside the flow definition, I see the StandardRestrictedSSLContextService with "identifier":"d7d70b6c-abe4-3564-a219-b289cb7f25d2" and both InvokeHTTP and ListenHTTP referencing that same UUID.
When I create a new Process Group using either the downloaded flow definition or the NiFi Registry flow, the StandardRestrictedSSLContextService is invalid as expected and it has a new UUID as expected. I enter the keystore and truststore passwords and enable the service. Only one processor references the new StandardRestrictedSSLContextService. The other processor is still invalid because it references the old UUID d7d70b6c-abe4-3564-a219-b289cb7f25d2 which does not exist.
> Versioned flow with multiple components referencing same controller service will only have 1 valid component after import
> -------------------------------------------------------------------------------------------------------------------------
>
> Key: NIFI-12394
> URL: https://issues.apache.org/jira/browse/NIFI-12394
> Project: Apache NiFi
> Issue Type: Bug
> Components: Flow Versioning
> Reporter: Michael W Moser
> Priority: Major
>
> I built a Process Group containing one StandardRestrictedSSLContextService that is referenced by an InvokeHTTP and a ListenHTTP processor. I downloaded that Process Group as a flow definition with external services. I also versioned that Process Group in NiFi Registry.
> Inside the flow definition, I see the StandardRestrictedSSLContextService with "identifier":"d7d70b6c-abe4-3564-a219-b289cb7f25d2" and both InvokeHTTP and ListenHTTP referencing that same UUID.
> When I create a new Process Group using either the downloaded flow definition or the NiFi Registry flow, the StandardRestrictedSSLContextService is invalid as expected and it has a new UUID as expected. I enter the keystore and truststore passwords and enable the service. Only one processor references the new StandardRestrictedSSLContextService. The other processor is still invalid because it references the old UUID d7d70b6c-abe4-3564-a219-b289cb7f25d2 which does not exist.
> edit: I tried this using a controller service that does not have sensitive properties, and did not have this problem, so it could be related to sensitive properties.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)