- 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
