[
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)
