An alternative approach/future roadmap could be to consider integrating non-Git storage variants of the NiFiFlowRegistryClient into NiFi itself, e.g. the Filesystem, InMemory and Database variants from Registry itself.
That would allow users to take advantage of all of the good work that's gone into the main NiFi 2.x and future enhancements. Whether this is less work than maintaining the NiFi Registry itself, I'm not sure. Lucas's question of an alternative to the Bundle Store functionality provided by NiFi Registry would need some consideration too, e.g. would that get ported into NiFi longer term? Such a roadmap could start with the deprecation of NiFi Registry. Cheers, --- *Chris Sampson* Technical Lead, Solution Architect, Principal Software Engineer Naimuri Click here to join our newsletter <https://docs.google.com/forms/d/e/1FAIpQLSdkOWwC2zWL_vW0mlaoNl0RsbLvvvRi3R1L7V9DhcmRMlNmHw/viewform> On Tue, 4 Mar 2025 at 19:22, Arpad Boda <ab...@apache.org> wrote: > Based on Shane's efforts to modernise NiFi Registry UI I would prefer to > keep things as they are. I'm not aware of any concerns related to the > backend, so in case Shane and other members of the community contributing > to this effort can finish the works on the UI side I feel like there is > going to be no reason left to justify the works on moving Registry to a > different repository. > > On Tue, Mar 4, 2025 at 8:02 PM Chris Sampson > <chris.samp...@naimuri.com.invalid> wrote: > > > I am aware of environments where access to a Git server from the > > operational host/cluster that's running NiFi and NiFi Registry would not > be > > available due to security or other constraints. Loss of a non-Git based > > Flow version control option would impact such environments. That said, I > > imagine such setups are in the minority, which is possibly why there's > been > > less momentum in that regard over the past couple of years. > > > > I can see the utility in separating the Registry component to its own > > repository again would alleviate concerns around the main Apache NiFi > repo > > containing infrequently maintained code where vulnerabilities are > > increasingly likely to be identified, etc. It would, however, as Shane > > says, make it harder to maintain the UI inline with NiFi, although when > the > > community might get around to uplifting the existing Registry UI is > another > > question. > > > > > > Cheers, > > > > --- > > *Chris Sampson* > > Technical Lead, Solution Architect, Principal Software Engineer > > Naimuri > > > > > > Click here to join our newsletter > > < > > > https://docs.google.com/forms/d/e/1FAIpQLSdkOWwC2zWL_vW0mlaoNl0RsbLvvvRi3R1L7V9DhcmRMlNmHw/viewform > > > > > > > > > On Tue, 4 Mar 2025 at 18:35, Lucas Ottersbach <ottersb...@apache.org> > > wrote: > > > > > Thank you for opening the discussion David. > > > > > > We also make use of the NiFi registry both for Flow versioning and > > > automatic distribution of custom .nar artifacts to the clusters. > > > > > > We thought about moving Flow versioning to a Git provider to both: > > > - profit from improved version history, and > > > - investigate more elaborate workflows in hope of improving > collaboration > > > using branches. > > > As of now however, we still rely on (multiple instances of) the > registry. > > > > > > Is there a good alternative for our second use case available, that is > > > distribution mechanism for .nar artifacts without using the NiFi > registry > > > or actively pushing files onto the cluster nodes? > > > > > > > > > Best regards > > > > > > Lucas > > > > > > Joe Witt <joe.w...@gmail.com> schrieb am Di., 4. März 2025, 18:22: > > > > > > > What versions Russ? > > > > > > > > On Tue, Mar 4, 2025 at 10:15 AM Russell Bateman < > r...@windofkeltia.com > > > > > > > wrote: > > > > > > > > > We don't use a separate Git repository; only the simple solution > the > > > > > NiFi Registry offers. > > > > > Maybe someday we'll go further, but, in the meantime, It's super > > useful > > > > > to us so we hope > > > > > never to see it disappear. > > > > > > > > > > Thanks, > > > > > Russ Bateman > > > > > > > > > > On 3/4/25 08:44, David Handermann wrote: > > > > > > Team, > > > > > > > > > > > > For more than two years, the NiFi Registry project has received > > > > > > minimal maintenance attention. This is apparent from a review of > > > > > > commits related to the nifi-registry directory [1], the majority > of > > > > > > which are incremental dependency version upgrades. As project > > > > > > maintainers, we need to decide on a support strategy going > forward. > > > > > > > > > > > > The lack of maintenance for NiFi Registry is clear when reviewing > > > > > > important elements of the project itself. On the frontend, this > > > > > > includes Angular 11, which is no longer supported, and last > updated > > > > > > over three years ago. Other issues include a historical approach > to > > > > > > application token management, which NiFi itself changed in > version > > > > > > 1.15.0, and legacy integration with OpenID Connect. Current > > community > > > > > > work has focused on direct integration with Git-based Flow > Registry > > > > > > Clients, including GitHub, GitLab, and BitBucket. With the Flow > > > > > > Registry Client as an extension point itself, the NiFi framework > is > > > > > > effectively decoupled from NiFi Registry as the solution for > > version > > > > > > control of flow definitions. > > > > > > > > > > > > The NiFi Registry project previously existed in a separate > > repository > > > > > > until 2021 [2], and at the time, there were some advantages to > > > > > > co-locating projects. With the decoupling of the client > interface, > > > > > > however, there seems to be little value in continuing to maintain > > the > > > > > > project in the same repository. > > > > > > > > > > > > With minimal maintenance over multiple years, we should seriously > > > > > > consider deprecating NiFi Registry for removal. As an > intermediate > > > > > > step, however, moving NiFi Registry back to a separate repository > > > > > > would have multiple benefits. It would focus the maintenance > > concerns > > > > > > for NiFi and NiFi Registry independently, clarifying where work > is > > > > > > happening, and where it is needed. It would also provide the > > > > > > opportunity for focused improvements to NiFi Registry, if there > is > > > > > > remaining support for it among project PMC members and > committers. > > > > > > > > > > > > I'm willing to put in the work to decouple the projects, so it > > would > > > > > > be helpful to get some feedback from the community, and from > active > > > > > > contributors in particular, about future maintenance for NiFi > > > > > > Registry. > > > > > > > > > > > > Regards, > > > > > > David Handermann > > > > > > > > > > > > [1]https://github.com/apache/nifi/commits/main/nifi-registry > > > > > > [2]https://issues.apache.org/jira/browse/NIFI-8528 > > > > > > > > > > > > > > >
