nifi-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Evan Reynolds <>
Subject Re: [DISCUSS] Next version of NiFi Registry after 0.5.0
Date Tue, 27 Aug 2019 18:28:35 GMT
I'd love to suggest working on improvements to avoid merge conflicts, and also more intelligence
in connecting things like controller services.

Merge conflicts:
We are using the registry to deploy flows to production. We have conflicts far too frequently
in the pipeline, and as there is no way to merge we are left manually replicating one set
of changes over the other set of changes, then roll that set back. 

We have been working on processes to avoid that, but I do not think we're ever going to fully
succeed. __ I would love to have a discussion of how to avoid that! I know there aren't easy
fixes (we can merge the XML files but how to prove that is actually the desired result would
be a nightmare) but how many hooks does the registry have in NiFi? Could it monitor the deployed
flows, for example, and if one flow changed could it lock the other deployments so that if
someone tried to change them they'd get notified that they were about to create a problem
so that they could avoid it?

I'm not saying that is a good plan. But it's there to start a discussion mostly!

Controller services:
I have a controller service that I can only have one of due to resource limitations, but several
flows use it. When I deploy a flow, since the controller service is not inside that flow,
it doesn't deploy with that connection hooked up correctly so I have to go fix several places.
I'd love to improve that somehow!

Evan Reynolds

´╗┐On 8/26/19, 2:56 PM, "Mike Thomsen" <> wrote:

    I'd like to see the extension registry at the top of the list, as well as
    discussions about what sort of workflows are envisioned to make the
    Registry useful for DevOps teams. For example, would we want to have
    integration with Nexus and similar tools to allow a CI/CD tool to push
    builds into the central repository and let the Registry pull them down or
    should we go for pushing directly to the Registry?
    On Mon, Aug 26, 2019 at 11:42 AM Bryan Bende <> wrote:
    > Typically after a release we set master to the next second digit
    > version (i.e. release 0.5.0 and then master goes to 0.6.0-SNAPSHOT),
    > but I wanted to discuss the idea of working towards a 1.0.0 release
    > for NiFi Registry.
    > I've been doing some work to support an HA deployment of NiFi Registry
    > and it requires breaking changes to the REST API to introduce an
    > optimistic locking strategy. I'd like to be able to land this work in
    > master in the near future.
    > I wanted to see what other work/changes we might want to target for a
    > 1.0.0 release. One big item would be Java 11 support, but technically
    > we can do that without a major release (just like we are doing in
    > NiFi). The question would be whether we want NiFi Registry 1.0.0 to
    > make Java 11 the minimum, and if so, then at what point would we be
    > ready to do that.
View raw message