Hello, When you version control a process group, it captures all components in that group and child groups. If a component references a controller service from a parent group, then when you import this process group to the next environment you will have to re-link that component to the appropriate service in the parent group of the new environment. You only have to make this change when time during initial import. After that on future upgrades it will retain the link to the service.
The reason it works this way is because NiFi can't know for sure what service in the new environment to select since its a service that was not part of version control. There is a JIRA for a future improvement to attempt to auto-select the service from a parent group when there is only one service of the required type with the same name (name is not unique so if there is more than one with the same name we can't know which one to select). -Bryan On Wed, Apr 10, 2019 at 5:17 AM Max <[email protected]> wrote: > > Hello! > > I’d like to use registry for deploying my flows in various environments. > > Let’s say on dev I create a flow that has an ExecuteSQL processor and this > processor references a db controller service, which is defined on the root > level. > > I then version my flow and commit. Next, I go to my production env and import > the flow. The result is that the ExecuteSQL processor on prod > will be not enabled because the property “Database Connection Pooling > Service” will say “Incompatible Controller Service configured” where on dev I > had the db referenced. > > Maybe I don’t get versioning in NiFi yet but how is that supposed to work to > reference controller services (db connections in particular) that are defined > on the root level when using registry?
