Would the community support the maintenance of a DatabaseFlowRegistryClient to take the place of the NiFi Registry DatabaseFlowPersistenceProvider?
-- Mike On Fri, Jan 16, 2026 at 10:18 AM Pierre Villard <[email protected]> wrote: > - Dirk, > > I'm not sure I'm following the scenario that you're describing. Are > you saying that you're adding a new version of an existing NAR? and > you want to update the version of the already instantiated components > of that NAR to use the new version? > > To not have this thread going into many directions, I recommend filing > a JIRA (or a new thread on the mailing list) and happy to follow-up > there. > > - Geoff, > > I'll answer on the JIRA you filed but thanks for bringing this up. > There is one aspect that is configuration driven but another one seems > to be a bug that should be addressed. I'll confirm on my side and > follow up on the JIRA you created [1]. > > [1] https://issues.apache.org/jira/browse/NIFI-15475 > > Thanks, > Pierre > > > Le jeu. 15 janv. 2026 à 22:22, Greene (US), Geoffrey N via users > <[email protected]> a écrit : > > > > So, under the assumption that nifi-registry [which we rely quite heavily > on] is going to go away, I looked at the replacement, which I gather is > GitlabFlow Registry client (with a gitlab backing store) > > > > With both nifi 2.7.2 and nifi 2.6.0: > > > > > > > > Create a simple flow, and check it into the Gitlab FlowRegistry. > > Reimport that flow, so we now have TWO identical copies of that flow > > Change one copy of the flow, and check it in > > The red upgrade needed flag in the upper left corner of the OTHER flow > doesn’t appear after many minutes. The greene checkmark remains on both, > even though one is out of date. This is really bad for us. > > Unfortunately, and to make things worse, if you then attempt to make > another change in the OTHER flow, it doesn’t recognize the conflict, and > that change actually overwrites the change you made in step 3. > > > > > > > > This is going to have to be fixed in order for us to move from git > registry to the new gitlabflow. We have multiple copies of many of our > flows (code reuse, what a concept), and we need to know when something is > out of date. > > > > > > > > This seems related to NiFi-14478 but that was supposedly fixed in > September 2025, and claims to have a fix version of 2.6.0, yet it continues > to be an issue in nifi 2.7.2. > > > > > > > > To be clear this is only an issue with gitlab flow, not with git > registry. > > > > > > > > Restarting nifi between steps 3 and 4 does mitigate the issue, but isn’t > a good fix. > > > > > > > > Thanks > > > > > > > > > > > > > > > > > > > > > > > > > > > > Geoff Greene > > > > ATF / Senior Software Ninjaneer > > > > > > > > > > > > From: Yuanhao Zhu <[email protected]> > > Sent: Tuesday, January 13, 2026 3:07 AM > > To: [email protected] > > Subject: [EXTERNAL] Re: [DISCUSS] Proposal to Deprecate NiFi Registry > > > > > > > > EXT email: be mindful of links/attachments. > > > > > > > > > > Hey guys, > > > > > > > > Thanks for triggering the discussion. From our point of view, we don't > mind switching to the git-based flow versioning. However, maybe this is not > relevant, are you planning to integrate full git support for single flow > versioning? Like branching/rebase/merge for single flow as well? We've > noticed the git-based registry client since migration to 2.x, but we didn't > choose to switch using that because at the end of the day it still does not > enable the flow versioning like git. Yes, you can create branches, but only > from the repository side, not nifi side, and I cannot create a branch for a > specific flow, but only the entire registry. Also, the merging/rebase is > not possible for single flow from nifi side. If the git based registry > client actually full support those operations, I think at least we will try > to switch to using that ASAP(hopefully more people would agree) cuz it > would provide so much more benefit > > > > > > > > BR > > > > > > > > Yuanhao > > > > ________________________________ > > > > From: David Handermann <[email protected]> > > Sent: Monday, 12 January 2026 21:48 > > To: [email protected] <[email protected]> > > Subject: Re: [DISCUSS] Proposal to Deprecate NiFi Registry > > > > > > > > CAUTION: This email originated from outside of the organization. Do not > click links or open attachments unless you recognize the sender and know > the content is safe. > > > > Pierre, > > > > Thanks for initiating this discussion, I concur with your summary of > > the situation. I believe your proposal is the best way forward under > > the circumstances. > > > > Although a large part of the maintenance relates to the user > > interface, as I mentioned almost a year ago [1], the minimal amount of > > maintenance relates to Registry as a sub-project in general. Aside > > from the substantive progress that Shane and Scott have made on > > bringing the UI to a maintainable state, the rest of the sub-project > > has received little attention. Lack of change might prompt one to > > think that the sub-project does not need maintenance, but a quick > > comparison to NiFi itself should underscore the fact that maintenance > > is required. It is not a matter of writing up potential areas to > > address, but instead a matter of available active committer cycles. > > > > As Pierre highlighted, project contributor focus and activity has > > shifted to direct Flow Registry Client integrations, and that should > > be the path forward. > > > > It is helpful to understand current usage and potential feature gaps, > > and active project maintainers should take this feedback into > > consideration. Given limited maintenance cycles, however, it is > > essential to focus on what is maintainable, and what needs to be > > abandoned. > > > > Following Pierre's emphasis, the core question is active maintainers > > willing to do the work right away. The corollary question is whether > > that work should be done given alternatives. > > > > I have some additional thoughts, but will hold off for now for > > additional comments to come in. > > > > Regards, > > David Handermann > > > > [1] https://lists.apache.org/thread/xwcrqww4q3yzyq8z3jfbzg55sosnrdx0 > > > > On Mon, Jan 12, 2026 at 2:19 PM Mike Brown <[email protected]> > wrote: > > > > > > Am i understanding this that you are proposal removinal use of Nifi > Registry completely and moving to an option where Nifi can directly > communicate with git and store the configurations in a project in there? > > > > > > On Mon, Jan 12, 2026 at 3:13 PM Shane Ardell <[email protected]> > wrote: > > >>> > > >>> The UI modernization effort has stalled, and > > >>> there is currently no clear path to completion without significant > > >>> volunteer contributions. > > >> > > >> > > >> I've been working with Scott Aslan over the past half year rewriting > the Registry UI. Here is a list of commits made contributing toward the new > Registry UI [1] and the significant progress made. The last piece of work > [2] that was merged into the codebase was on November 6th last year, so > about 8 weeks of inactivity in GitHub. I apologize if it looks like we > stalled, but that definitely is not the case for those of us working on the > task. I just happened to take some holiday time towards the end of last > year, and I'm guessing Scott did as well. > > >> > > >> I reached out to Scott last Friday to discuss the last significant > piece of the rewrite [3], which I offered to start work on. Once that is > complete, the only remaining necessary work would be to include it in the > maven build [4]. > > >> > > >> Reasons why we'd like to keep Registry in the NiFi project are > mentioned in an email thread from last year having a very similar > discussion [5]. > > >> > > >> We have been working in a bit of a bubble (outside of PR feedback we > chat directly on NiFi's Slack workspace) which doesn't help the greater > community understand our progress. Perhaps it would help if we had a > dedicated channel for the rewrite in Slack to give better visibility into > where we're at and have a record of these discussions. I'm also open to > other ideas regarding more open communication as we continue toward > finishing this piece of work. > > >> > > >> Best, > > >> Shane > > >> > > >> [1] > https://github.com/apache/nifi/commits/main/nifi-frontend/src/main/frontend/apps/nifi-registry > > >> [2] https://github.com/apache/nifi/pull/10399 > > >> [3] https://issues.apache.org/jira/browse/NIFI-14321 > > >> [4] https://issues.apache.org/jira/browse/NIFI-13940 > > >> [5] https://lists.apache.org/thread/xwcrqww4q3yzyq8z3jfbzg55sosnrdx0 > > >> > > >> > > >> On Mon, Jan 12, 2026 at 11:50 AM Pierre Villard < > [email protected]> wrote: > > >>> > > >>> Hello NiFi community, > > >>> > > >>> I'd like to start a discussion about the future of NiFi Registry and > > >>> propose that we deprecate this component. > > >>> > > >>> **Current State** > > >>> NiFi Registry has accumulated a significant number of security > > >>> vulnerabilities (CVEs) related to its Angular-based frontend, with > the > > >>> count now reaching double digits. Unfortunately, these CVEs cannot be > > >>> resolved through simple dependency updates. The only viable path to > > >>> address the security issues requires completing a full rewrite of the > > >>> Registry UI to use modern Angular, an effort that was started but > > >>> remains incomplete as of today. > > >>> > > >>> **Maintenance Challenges** > > >>> Over the past several years, NiFi Registry has received minimal > > >>> maintenance attention. The UI modernization effort has stalled, and > > >>> there is currently no clear path to completion without significant > > >>> volunteer contributions. While an initial PR was submitted and > merged, > > >>> the remaining work—including user/group management pages, > > >>> comprehensive testing, etc—still needs to be addressed. As a PMC, we > > >>> have an obligation to respond to CVEs in software we release. > > >>> Continuing to ship NiFi Registry with known, unresolved security > > >>> vulnerabilities is not sustainable. > > >>> > > >>> **Alternatives Available** > > >>> NiFi 2.x introduced direct integration options with Git-based > registry > > >>> clients that provide an alternative path for flow versioning: > > >>> - Git-based registry clients offer native integration with existing > > >>> version control infrastructure > > >>> - These clients are actively maintained and do not carry the same > security debt > > >>> > > >>> The main feature gap is the permission model in NiFi Registry that > > >>> allows users to access specific flows based on permissions (useful > for > > >>> multi-tenant deployments). With Git-based clients, access control is > > >>> typically all-or-nothing at the repository level. However, the > > >>> advantages of Git-based registry clients largely compensate for this > > >>> limitation for most use cases. > > >>> > > >>> **Maintenance Requirements** > > >>> If you or your organization depends on NiFi Registry and would like > to > > >>> see it continue as part of the project, now is the time to step > > >>> forward and contribute to its maintenance. The work required > includes: > > >>> - Completing the Angular UI rewrite > > >>> - Complete testing following the full rewrite > > >>> - Backend changes to have feature parity in terms of OIDC/SAML > support > > >>> for authentication, remove support for Kerberos, etc > > >>> > > >>> **Proposal** > > >>> I propose that we: > > >>> - Immediately deprecate NiFi Registry - Mark it as deprecated in the > > >>> documentation and codebase, clearly communicating to users that they > > >>> should migrate to alternative solutions. > > >>> - Set a removal timeline - Plan to remove NiFi Registry from the > > >>> codebase as part of NiFi 3.0, giving users adequate time to migrate. > > >>> - Welcome community contributions - If any community members or > > >>> organizations rely on NiFi Registry and wish to maintain it, we > > >>> welcome contributions to complete the UI rewrite and address the > > >>> outstanding CVEs. The deprecation decision could be revisited if > > >>> substantial progress is made. > > >>> > > >>> Without active maintainers willing to do this work right away, > > >>> deprecation and eventual removal is the responsible path forward. > > >>> I look forward to hearing the community's thoughts on this proposal. > > >>> > > >>> Thanks, > > >>> Pierre > > > > > > > > > > > > -- > > > > > > MIKE BROWN > > > > > > [email protected] > > > > > > > > > DISCLAIMER: The content of this email is intended for the person or > entity to which it is addressed only. This email may contain confidential > information. If you are not the person to whom this message is addressed, > be aware that any use, reproduction, or distribution of this message is > strictly prohibited. If you received this in error, please contact the > sender and immediately delete this email and any attachments. >
