I believe it is NiFi 1.10.0 and registry 0.5.0 that will give you the matching behavior described by Mark.
On Tue, Sep 8, 2020 at 1:11 PM Mark Payne <marka...@hotmail.com> wrote: > John, > > What version of NiFi/Registry are you using? > > NiFi will first attempt to match “external Controller Services” (meaning > external to the Process Group being imported) based on an ID, as you > describe. But with the latest version of NiFi (I do not recall off the top > of my head whether or not a specific version of the Registry is required), > if no Controller Service can be found with the appropriate ID, it will try > to match them up by Controller Service name and type. So, if you have a > DBCPConnectionPool named “My Connection Pool” in your first environment, > and you want to import that into a second environment, you can create a > DBCPConnectionPool in the second environment with the name “My Connection > Pool” and then when you import your flow, NiFi should handle matching up > the Controller Service by name. > > Hope this helps! > -Mark > > > On Sep 8, 2020, at 12:59 PM, jgunvaldson <jgunvald...@cox.net> wrote: > > We are working through various alternatives for migration of flows from > our old DEV environment to other (new DEV, QA and PROD) > > Currently the approach we use invalidates all processors that use > controller services established on root and domain flow level (import of > FLOW does not duplicate GUID from root canvas) - in a sense using the > process of creating a new Processor and import from old registry bucket. > > Problem starts with the way NiFi stores processor information in registry > by referencing controller services by ID and parentGroupId. > > However, controller services and domain processor groups in the new DEV, > QA or PROD environments were created using UI (in preparation , and they > are of course assigned a different ID (GUID). Thus, when attempting the > import process, the Import process fails to match them and does not set > controller services properties for processors that use those controller > services which leaves those processors in invalid state. > > We are looking at various multiple potential solutions: > > > - Developers fix their flows manually. This would introduce a large > workload (in my case one flow would have 200+ processor to be fixed) for > developers that rely on controller services established on root level > (database connections, distributed map cache etc) > - We have a team run automation scripts to match controller services > by name (how often to run script, after each import?) > - We administrators change IDs in new DEV, QA or PROD flow definition > file to match old DEV environment > - We administrators create new DEV, QA ir ORID environment using > truncated (root and domain flow) flow definition file from old DEV > environment > - We administrators create a process to create controller services and > domains that does not rely on NiFi UI in a way that will ensure that all > root/domain level controller services and root/domain level flows have > the same ID > > These are some ideas we have - but I am very interested in how the > community has solved importing your flows from one (old) environment into a > newly created environment, when the controller services GUID will not match > on import - and invalidates the flow - and developer may have to “FIX” > hundreds of properties? > > > Thanks in advance > ~John Gunvaldson > > >
