Thanks to everyone for the replies thus far. It is great to hear progress on the work involved with upgrading to a supported version of Angular. If that is ready to land as a pull request soon, then it makes sense to keep Registry is the repository for now.
Regarding other issues, as I mentioned, there are some fundamental implementation details that need to be modernized around token handling and OIDC integration. Revisiting the bootstrap process, similar to NiFi 2, would also more important. I write these up as Jira issues for further tracking. As Joe highlighted, however, the fundamental question relates to Registry itself as the supported way to provide version control for flows. Lucas also raises a good question about NAR bundle access, as the Flow Registry Client is focused on version control. On this front, recent work around the REST API for direct NAR upload is one thing worth noting, but I think there is some additional design and development work involved for a full story around artifact retrieval. On the version control front, having Registry as an intermediary to a real system like Git is not ideal. The Flow Registry Client makes this feature extensible, so as time goes on, continuing to maintain NiFi Registry for a less-than-ideal version control solution does not seem tenable. For the short term, it would be great to see the Angular upgrade landing soon. After that lands, that seems like a good opportunity to evaluate things in terms of both repository location and long term direction. If we find things not yet upgraded by this summer, that also bears revisiting. Regards, David Handermann On Tue, Mar 4, 2025, 3:37 PM Russell Bateman <r...@windofkeltia.com> wrote: > We're quite a ways back, but I do the development and I run on 1.28.1 > (both NiFi and NiFi Registry). We have plans to move to 2.x someday. > It's hard to get customers to move forward. > > > On 3/4/25 10:22, Joe Witt wrote: > > 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 >
