Thanks for the recap Bryan. I'm a +1 on option 3. Pierre
Le mer. 28 août 2019 à 15:35, Bryan Bende <[email protected]> a écrit : > I think Pierre summed exactly what I was trying to get at. I realize > now that I did a poor job of explaining, but it seemed like there were > three approaches we could take... > > 1) Master becomes 0.6.0-SNAPSHOT and we continue on like normal. My HA > work has to sit somewhere indefinitely, either a draft PR or a branch, > and it likely ends up getting harder and harder to keep in sync with > master as time goes on. > > 2) Master becomes 1.0.0-SNAPSHOT, the HA work I'm doing can be merged > whenever its ready, and we wait until we make Java 11 the min > requirement to make the 1.0.0 release, but this could take who knows > how long (6 months, 12 months ?) and there would be no releases during > that time. > > 3) Master becomes 1.0.0-SNAPSHOT, the HA work I'm doing can be merged > whenever its ready, we make the 1.0.0 release whenever its ready with > Java 8/9/11 support, and then later we do a 2.0.0 release for Java 11 > min requirement, we just might have some short live 1.x line, but that > shouldn't really matter. > > I think #3 is probably the most realistic option. > > All of the other ideas suggested are good items to keep in mind, and > definitely represent valuable functionality, but as far as I know, > they could be implemented on any second digit release within 0.x or > 1.x, its really the breaking changes I was trying to identify that > would warrant going to a third digit release. > > > On Wed, Aug 28, 2019 at 4:56 AM Pierre Villard > <[email protected]> wrote: > > > > If we believe that NiFi 2.x will only support Java 11+, should we do the > > same for NiFi Registry 1.x? It'd probably be more consistent for users, > no? > > Or... if we think that NiFi 2.x is not going to happen soon, we could > have > > a "short lived" Registry 1.x branch with Java 8/9/11 support, and then > have > > Registry 2.x when we go for Java 11+. > > > > Other than that, strong +1 for moving to a 1.x branch and have the new > > features with the API changes. > > > > Le mar. 27 août 2019 à 23:16, Andy LoPresto <[email protected]> a > écrit : > > > > > I am definitely a +1 on moving to 1.0.0-SNAPSHOT and allowing the API > to > > > change to support the new functionality. > > > > > > Andy LoPresto > > > [email protected] > > > [email protected] > > > PGP Fingerprint: 70EC B3E5 98A6 5A3F D3C4 BACE 3C6E F65B 2F7D EF69 > > > > > > > On Aug 27, 2019, at 3:02 PM, Bryan Bende <[email protected]> wrote: > > > > > > > > Evan, > > > > > > > > Thanks for the input... definitely some improvements around merging > > > > and concurrent modifications that can be made, although we have to > > > > figure out which parts of these are actually in NiFi Registry code vs > > > > NiFi code. Many times a lot of this logic is implemented on NiFi > side. > > > > > > > > Regarding your feedback about controller services, this will be > > > > resolved in NiFi 1.10.0 + Registry 0.5.0 :) it will now auto-resolve > > > > services by name from a parent group, as long as there is only one > > > > service with that name and type (name is not unique in NiFi). > > > > > > > > > > > > Mike, > > > > > > > > Great points. I think we need to divide extension registry into two > > > > different things... > > > > > > > > 1) General functionality to support versioned extensions > > > > 2) The centrally hosted extension registry for the Apache community. > > > > > > > > The reason I say this is because #2 has a whole set of separate > things > > > > to figure out like where is it going to be hosted, who is going to > pay > > > > for it, how is the community going to manage releases of NARs > > > > (restructuring of repos), etc, and while all of that is very > > > > important, I don't think it is really related to whether or not we > > > > would release a specific version of NiFi Registry. > > > > > > > > For #1, most of the work that is needed on NiFi Registry side is > > > > already done. We need the NiFi 1.10.0 release which provides the > > > > changes to nifi-api that allow a NAR to be uploaded to Registry > > > > 0.4.0/0.5.0, and we also need the CLI from 1.10.0 which provides > > > > commands for making it easy to upload NARs from scripts. > > > > > > > > The missing pieces are more on the NiFi side of things... stuff like > > > > how does someone install/manage extension bundles from the NiFi UI or > > > > REST API, how does NiFi import a versioned flow and automatically > > > > install the missing bundles, etc. These things would all be > > > > implemented in NiFi. > > > > > > > > For pushing builds, we can definitely look at integration with Nexus, > > > > and I was also thinking about having another Maven plugin like > > > > "nifi-registry-maven-plugin" which would release your NAR to registry > > > > as part of a given Maven lifecycle. > > > > > > > > > > > > On Tue, Aug 27, 2019 at 2:28 PM Evan Reynolds > <[email protected]> > > > wrote: > > > >> > > > >> 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. > > > >>> > > > >> > > > > > > >
