I am ok with deprecating the NiFi Registry with the caveat that Pierre mentioned that "[t]he deprecation decision could be revisited if substantial progress is made." Although I can't contribute any UI code, I'd like to see things like Registry Replication, where Registries can leverage a Registry Client to push/pull to other Registries. 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. Also having the Registry secure by default like we did with NiFi (if that work is not already done or in progress).
- Matt On Wed, Jan 14, 2026 at 4:27 AM Pierre Villard <[email protected]> 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. > > 2. There is a NIP [2] discussing the introduction of a new concept: > Extensions Registry Clients. It would be a much better version of what > can be done today with the NiFi Registry. I think this is something > that would be extremely useful, especially in the world of running > NiFi on k8s. I did build a PoC for it but it will need a lot of work > before it can be a real thing in NiFi, assuming this is accepted by > the overall community. > > [1] https://nifi.apache.org/nifi-docs/rest-api.html#uploadNar > [2] https://issues.apache.org/jira/browse/NIP-4 > > Thanks, > Pierre > > Le mer. 14 janv. 2026 à 06:57, Dirk Olmes <[email protected]> a écrit : > > > > On 1/13/26 12:08 PM, Pierre Villard wrote: > > > Thanks all for the feedback so far. Just my thoughts on some comments > > > that have been made. > > [snip] > > > > I'd like to add one more aspect to the discussion of deprecating the > > registry: nar autloading from external sources. Right now there are two > > implementations available: registry and HDFS. If registry is deprecated > > that would leave only one alternative. Hadoop would be a bit heavy to > > host just for NARs. > > > > I know about nifi.nar.library.autoload.directory but that approach does > > not work eitehr, unfortunately because I am running on Kubernetes. When > > I mount the autoload directory into the pod I'm on a filesystem that > > does not propagate filesystem events so the whole autload mechanism does > > not work either. > > > > -dirk >
