[
https://issues.apache.org/jira/browse/NIFI-14944?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18018785#comment-18018785
]
Pierre Villard commented on NIFI-14944:
---------------------------------------
Controller Services are a specific case where we first lookup by name. This is
because if moving from one environment to another and you have "external
controller services" (meaning defined outside of the process group, like at the
root level), we need to reference those by names since the UUID would be
different across environments. My guess is that in your case you have created
new controller services that are now at the process group level and are
referenced by the Reader/Writer but I assume (please correct me if not) they
have the same name as the previously higher-level referenced controller
services and I think this is why the reference has not changed. I think that is
the controller service names are different, this should work as expected.
Not saying this cannot be improved, but this would be my random guess as to why
this is behaving like this and you observe this behavior.
> 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)
