> This would provide a live way to move from NiFi Registry to a Git-backed one > for example, rather than Export All then Import All.
I agree Matt, ideally, as part of deprecation & preparing for NiFi 3, it would be ideal to have a clear migration guide / tool for migrating from NiFi Registry to a git-based NiFi Registry Client On Thu, Jan 15, 2026 at 2:59 AM Dirk Olmes <[email protected]> wrote: > > On 1/14/26 1:26 PM, Pierre Villard wrote: > > - Dirk, > > > > You're absolutely right. I just want to mention a couple of things: > > > > 1. With NiFi 2, some APIs [1] have been added allowing users to push > > NARs into NiFi (as well as managing its lifecycles). So it can be an > > option for pushing custom NARs into NiFi. I do understand that it > > changes the approach given that with what you're talking about, NiFi > > is pulling NARs from an external location. In this case, you'd need to > > have a process in place to push NARs into NiFi. > > Thanks for the pointer to the API, Pierre. I played around with it and > after figuring out the nasty details I was able to push an updated > version of my processor into nifi. > > The API approach brings up new challenges, however. It seems I cannot > update a processor that was loaded e.g. by the autoload mechanism via > REST. This means that a restarted Nifi does not load the processors at > all. Which is quite a showstopper for our production flows that will > then come up in an invalid state until the procesors are loaded into > nifi externally. > > Any idea how I could solve this? > > Looking through the codebase I found LocalDirectoryNarProvider - > unfortunately only in the test code. I'll try experimenting with putting > this class into a custom nar and configuring a > nifi.nar.library.provider with it. > > -dirk
