[
https://issues.apache.org/jira/browse/NIFI-14944?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18018848#comment-18018848
]
Craig Patrick commented on NIFI-14944:
--------------------------------------
Hi [~pvillard], thanks for the response. In this instance, no the names were
actually different as everything we do is named based on the processor group it
belongs to. I think the services at the root level are called "Generic <X>
Thing" like in this instance I think it was "Generic CSV Reader (with Header)"
and then the new version was then named "DL CSV Reader (with Header)" to
indicate that it belongs to the DL processor group.
I'll see if I can recreate this issue from scratch as a use case to possibly
identify the issue.
> Updates to services in a processor do not get deployed via Registry despite
> being detailed in the update
> --------------------------------------------------------------------------------------------------------
>
> Key: NIFI-14944
> URL: https://issues.apache.org/jira/browse/NIFI-14944
> Project: Apache NiFi
> Issue Type: Bug
> Components: Flow Versioning
> Affects Versions: 2.0.0
> Environment: All
> Reporter: Craig Patrick
> Priority: Major
>
> Not sure if the title make sense - but when making changes to a controller
> service and then committing those changes into registry it does not seem to
> take effect when being deployed to the target system.
> Example:
> * Created a process group ("Working Group") which has some processors which
> access controller services from the root workflow ("NiFi Flow") - for example
> a simple CSV Reader and Writer.
> * Deploy this initial PG to the DEV environment referencing existing
> controller services from the "root" workflow.
> * Updated the processors within this process group to now use CSV reader and
> writer services from the current processor group scope ("Working Group")
> instead of the root (so they get committed within the group, and can be
> deployed to any system with the services - and also because we're getting rid
> of "root controller services")
> * Commit these changes with the updated references and then deploy these
> changes to the DEV environment.
> * Within the update logs, we can see the references to the controller
> services have been updated and so I would expect those to be updated:
> **
> {code:java}
> Property 'Record Reader' for Processor with ID
> 7e472cda-8671-36a6-efdd-ce227d6ea8d3 is different
> Controller Service with ID 0fa3447c-0199-1000-1117-34a05a6692cf exists in
> Proposed Flow but not in Currently Loaded Flow
> Property 'Record Writer' for Processor with ID
> 66e060ad-6e9f-3c9b-d9b4-227a15dd5b75 is different
> Controller Service with ID 0fa10b90-0199-1000-77af-b54d67c67107 exists in
> Proposed Flow but not in Currently Loaded Flow{code}
> * However, when we check the actual processors, they are still referencing
> the services from the root ("NiFi Flow") scope and not the new services which
> we have created and deployed. I need to manually make changes to the
> processor(s) to use the new services instead of the root ones. It's worth
> noting that this doesn't register as a change which needs to be committed so
> not sure exactly what is going on, as surely service changes should require a
> commit?
> * If this is the case, then maybe it's registering it as changing to the new
> services but the UI is not updating accordingly and still referencing the old
> services only in the UI?
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
