Re: [DISCUSS] Proposal to Deprecate NiFi Registry
>> 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 >> > >> 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 >> > >> > 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? Lik
Re: [DISCUSS] Proposal to Deprecate NiFi Registry
i 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 > > >> > 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 > > >> > Sent: Monday, 12 January 2026 21:48 > > >> > To: [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 i
Re: [DISCUSS] Proposal to Deprecate NiFi Registry
e > >> > 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 > >> > 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 > >> > Sent: Monday, 12 January 2026 21:48 > >> > To: [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-
Re: [DISCUSS] Proposal to Deprecate NiFi Registry
Hi Mike, Regarding the suggestion to add a DatabaseFlowRegistryClient as a replacement for the NiFi Registry DatabaseFlowPersistenceProvider. That's an interesting suggestion. It would also allow for a simple migration strategy for current NiFi Registry users of the DatabaseFlowPersistenceProvider, while also addressing a lot of the security/vulnerability concerns with dependencies mentioned in this thread. Part of the reason (for me) that it would make sense to deprecate NiFi Registry and replace it with the Git-based registry clients is that git already supports rich version control semantics including branching, making it much more straightforward to build those features into NiFi flow versioning. Any database-backed client is going to have to build more the logic for versioning, branching, merging, etc into the client as those are not native operations the database persistence provider supports. This makes the implementation and maintenance more challenging. In deciding on a path forward, I think it is important to consider which active maintainers are available and willing to do the work near-term and over time. To be candid, I don't have the availability to contribute to the development of a DatabaseFlowRegistryClient, but if others submitted patches to the Apache repo with that functionality, I would not oppose it. Additionally, offering the RegistryClient interface as an extension point in the NiFi framework does allow for some flexibility for solutions to be developed outside of the Apache repo. Cheers, Kevin On Fri, Jan 16, 2026 at 12:28 PM Michael Moser wrote: > > 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 > 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 >> 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 >> > >> > >&g
Re: [DISCUSS] Proposal to Deprecate NiFi Registry
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 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 > 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 > > 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 > > Sent: Monday, 12 January 2026 21:48 > > To: [email protected] > > Subject: Re: [DISCUSS] Proposal to Deprecate NiFi Registry > > > > > > > > CAUTION: This email originated from ou
Re: [DISCUSS] Proposal to Deprecate NiFi Registry
- 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 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 > 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 > Sent: Monday, 12 January 2026 21:48 > To: [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
RE: [DISCUSS] Proposal to Deprecate NiFi Registry
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: 1. Create a simple flow, and check it into the Gitlab FlowRegistry. 2. Reimport that flow, so we now have TWO identical copies of that flow 3. Change one copy of the flow, and check it in 4. 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. 5. 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 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 mailto:[email protected]>> Sent: Monday, 12 January 2026 21:48 To: [email protected]<mailto:[email protected]> mailto:[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 mailto:[email protected]>> wrote: > > Am i understanding this that you are proposal removinal use of Nifi Registry > completely and moving to an o
Re: [DISCUSS] Proposal to Deprecate NiFi Registry
> 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. I agree Matt, ideally, as part of deprecation & preparing for NiFi 3, it would be ideal to have a clear migration guide / tool for migrating from NiFi Registry to a git-based NiFi Registry Client On Thu, Jan 15, 2026 at 2:59 AM Dirk Olmes wrote: > > On 1/14/26 1:26 PM, Pierre Villard 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. > > Thanks for the pointer to the API, Pierre. I played around with it and > after figuring out the nasty details I was able to push an updated > version of my processor into nifi. > > The API approach brings up new challenges, however. It seems I cannot > update a processor that was loaded e.g. by the autoload mechanism via > REST. This means that a restarted Nifi does not load the processors at > all. Which is quite a showstopper for our production flows that will > then come up in an invalid state until the procesors are loaded into > nifi externally. > > Any idea how I could solve this? > > Looking through the codebase I found LocalDirectoryNarProvider - > unfortunately only in the test code. I'll try experimenting with putting > this class into a custom nar and configuring a > nifi.nar.library.provider with it. > > -dirk
Re: [DISCUSS] Proposal to Deprecate NiFi Registry
On 1/14/26 1:26 PM, Pierre Villard 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. Thanks for the pointer to the API, Pierre. I played around with it and after figuring out the nasty details I was able to push an updated version of my processor into nifi. The API approach brings up new challenges, however. It seems I cannot update a processor that was loaded e.g. by the autoload mechanism via REST. This means that a restarted Nifi does not load the processors at all. Which is quite a showstopper for our production flows that will then come up in an invalid state until the procesors are loaded into nifi externally. Any idea how I could solve this? Looking through the codebase I found LocalDirectoryNarProvider - unfortunately only in the test code. I'll try experimenting with putting this class into a custom nar and configuring a nifi.nar.library.provider with it. -dirk
Re: [DISCUSS] Proposal to Deprecate NiFi Registry
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 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 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 >
Re: [DISCUSS] Proposal to Deprecate NiFi Registry
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
Re: [DISCUSS] Proposal to Deprecate NiFi Registry
- 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 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
Re: [DISCUSS] Proposal to Deprecate NiFi Registry
Thanks all for the feedback so far. Just my thoughts on some comments that have been made. - Shane, Scott, The community truly appreciates the work that has been done so far to rewrite the UI over the past half year. And I believe that regardless of this discussion, this work needs to happen anyway. As I said, we have a responsibility of addressing the CVEs for the software that we ship and the NiFi Registry has a very long list of CVEs as of today. Having said that, as David said, this is not the full picture. A lot of work would also need to happen on the backend side and we have not seen (significant) contributions for the NiFi Registry in a long time. I think that keeping the NiFi Registry as part of the Apache NiFi project would be great but it needs real ownership with enough contributions for a group of people that is large enough. This is the reason why I said the deprecation decision could be revisited whenever we start a discussion for NiFi 3 (which is not something I'm expecting soon). - Mark, Definitely agree that it would be a nice improvement and it would close the gap. I think this is a very fair approach. - Mike, That is correct, since NiFi 2, it is possible to configure Flow Registry Clients that are directly integrated with git-based solutions (as of today: Github, Gitlab, Bitbucket, Azure DevOps). This direct integration provides a lot of advantages compared to the integration with the NiFi Registry. - Yuanhao, > "Yes, you can create branches, but only from the repository side, not nifi > side" There is an open Pull Request to add support for creating branches from the NiFi side. This is something coming. Just need more people willing to review/test the many pull requests we have :) > "I cannot create a branch for a specific flow, but only the entire registry" This is how git-based solutions work: a branch is always for the complete repository, you cannot create a branch for specific files. > "the merging/rebase is not possible for single flow from nifi side" I have not seen any request for that before. Usually, flow developers would follow a more traditional developer UX where the changes via a branch are submitted through a pull request that can be reviewed and tested before it gets merged there and it can trigger CI/CD pipelines. Thanks, Pierre Le mar. 13 janv. 2026 à 09:07, Yuanhao Zhu a écrit : > > 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 > Sent: Monday, 12 January 2026 21:48 > To: [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
Re: [DISCUSS] Proposal to Deprecate NiFi Registry
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 Sent: Monday, 12 January 2026 21:48 To: [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 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 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 >> hav
Re: [DISCUSS] Proposal to Deprecate NiFi Registry
It is true that some progress towards a new UI has been made. However, there is still much to do and if the consensus is that the newer features are solving the communities use cases for flow versioning then I am in favor of promoting those as 'current best practices' and deprecating the Registry. -Scott On Mon, Jan 12, 2026 at 3:49 PM David Handermann < [email protected]> wrote: > 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 > 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 > 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
Re: [DISCUSS] Proposal to Deprecate NiFi Registry
Shane, Thanks for summarizing recent development efforts. For clarity, my statements are a reflection on the general status of NiFi Registry, not just the UI. The UI status is the most presenting concern, given the number of unresolved vulnerabilities. From the previous thread, however, I did not see any substantive responses to my larger concerns, which is why I think Pierre's proposal is the best option after considering sub-project activity over the last several years. Regards, David Handermann On Mon, Jan 12, 2026 at 2:48 PM David Handermann wrote: > > 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 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 > > 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 > >> 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
Re: [DISCUSS] Proposal to Deprecate NiFi Registry
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 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 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 >> 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, >>>
Re: [DISCUSS] Proposal to Deprecate NiFi Registry
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 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. >> -
Re: [DISCUSS] Proposal to Deprecate NiFi Registry
> > 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 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
Re: [DISCUSS] Proposal to Deprecate NiFi Registry
Thanks for the thoughtful write-up, Pierre. I support your proposal. While the need for version controlled flows still exists, a lot has changed since the introduction of NiFi Registry, and I believe the needs of most of the community are better met by the git-based registry client rather than the NiFi Registry Server implementation. As one of the original authors of the initial NiFi Registry implementation, I think if we were doing it over today we would consider a git repository client based approach for the design rather than a complimentary web service. I look forward to future improvements to version controlled flow definitions, such as the NIP-13 proposal for branch support [1], and I think deprecating the existing NiFi Registry Server implementation makes those plans more achievable. [1] https://issues.apache.org/jira/browse/NIP-13 Cheers, Kevin On Mon, Jan 12, 2026 at 12:50 PM Pierre Villard 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
