Hi folks I’m not sure where the functionality resides but could we include rotating certificates
Best regards Craig > On 28 Aug 2019, at 21:41, Pierre Villard <[email protected]> wrote: > > 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. >>>>>>> >>>>>> >>>> >>>> >>
