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 [email protected] On 8/26/19, 2:56 PM, "Mike Thomsen" <[email protected]> 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 <[email protected]> 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. >
