Isha and Russ, It might be tactically advantageous to explain this to your clients and leadership by focusing on the Spring angle because a lot of Java developers got slammed with this, so it may be a very relatable issue for them.
On Fri, Nov 8, 2024 at 3:41 AM Isha Lamboo <isha.lam...@virtualsciences.nl> wrote: > For what it's worth, I agree with David. This clearly is End of Life, so > let's not mince words. Anything else would be a disservice to the community. > > Thanks all for painting a clearer picture of why it's not doable or > possible license-wise to promise continued support. > > I'm off to figure out a mapping from inherited variables to inherited > parameter contexts and probably contact some vendors to see what their > support will look like. > > Thanks, > > Isha > > -----Oorspronkelijk bericht----- > Van: Joe Witt <joe.w...@gmail.com> > Verzonden: donderdag 7 november 2024 21:47 > Aan: dev@nifi.apache.org > Onderwerp: Re: [DISCUSS] End-of-life timing for NiFi 1 > > I'll avoid sharing more thoughts for now. I've shared enough. But I am > directionally on page with what Handermann/Moser just wrote. > > Thanks > > On Thu, Nov 7, 2024 at 1:33 PM David Handermann < > exceptionfact...@apache.org> > wrote: > > > I appreciate the sensitivity around end-of-life wording, but it is > > important to send a clear message. > > > > The project cannot provide security-related updates because the > > fundamental dependencies are already end-of-life: Jetty 9, Spring 5, > > and AngularJS 1.8. > > > > To provide any type of statement that implies future support would be > > inaccurate and misleading. We also need to provide a specific date in > > the short term to make it clear that we will not be accepting or > > backporting changes. > > > > The project management committee is responsible for handling releases > > and security findings, and as such, we need to make it clear what we > > can support. Although we might consider a rare exception for some > > fundamental framework bug not previously known, that should not be > > posted as an expressed or implied support for a future version. > > > > I'm open to calling it "end of development" or "end of support", but > > we should avoid semantics that obscure the reality. > > > > Regards, > > David Handermann > > > > On Thu, Nov 7, 2024 at 2:11 PM Michael Moser <moser...@gmail.com> wrote: > > > > > > I believe many people place a certain meaning on the End-Of-Life > > > label, interpreting it as "software that has reached EOL shall not > > > be used". I don't think that's the message we want to send about > > > 1.28 so soon after > > the > > > 2.0.0 release. > > > > > > I like Mike's suggestion of End of Development for 1.x and I concur > > > to remove the End Of Life/End Of Support words from Joe's #1 point. > > > There > > are > > > hidden meanings we won't fully comprehend. I recommend not even > > specifying > > > a future EOL date, because nobody will be happy with 30 days from > > > now > > (too > > > soon) and many will be unhappy with 12 months from now (too long to > > promise > > > resources to). > > > > > > I propose these words for Joe's #3 point on the downloads page. > > > > > > "Apache NiFi 1.28 will be the last minor version release in the 1.x > > > baseline. For the near future, only significant bug fixes and > > > security related updates will be considered for future patch > > > releases. The Apache NiFi team wishes to inform the community, > > > however, that several dependencies in 1.x cannot be upgraded past a > > > certain point. These include, but not limited to, versions of > > > software beyond Java 11, Jetty > > 9, > > > Spring 5 and AngularJS 1.8. For the most inclusive and continuing > > support > > > from the Apache NiFi team, we strongly encourage users to migrate to > > > NiFi 2.0" > > > > > > -- other Mike > > > > > > > > > On Thu, Nov 7, 2024 at 3:07 PM Mike Thomsen <mikerthom...@gmail.com> > > wrote: > > > > > > > Joe, > > > > > > > > I would modify the End of Life/End of Support to be End of New > > Development. > > > > From what I've seen over the years, End of Life/End of Support is > > typically > > > > used by vendors to imply a hard cut off date for free support. The > > > > way > > I > > > > take your proposal is that it's a message that new development and > > > > bug fixes will head to 2.X, but the community will get reasonable > > > > security support for a while, provided volunteers can be found to > > > > help out. It's that connotation of "hard stop" with End of Lie > > > > that I think warrants something like End of Active Development. > > > > > > > > At the end of the day, perhaps I'm overthinking this, but when I > > > > hear > > "End > > > > of Life," that's where my mind goes immediately. I think most > > > > people > > would > > > > immediately think that 1.28.1 is it, and if they can't get onto > > > > 2.X in > > a > > > > reasonable time, they might be taking on personal risk if an issue > > > > like log4shell comes up, and their leadership finds out that they > > > > have an unclear (to them) support path. It is technically clear > > > > (go to 2.X) but with any big effort with a lot of stakeholders, > > > > that might not be immediately viable, and I could see it quickly > > > > turn into a semantical > > fight > > > > over the meaning of "End of Life" for people trying to support 1.X > > > > and > > make > > > > the case for 2.X in that environment. > > > > > > > > > > > > On Thu, Nov 7, 2024 at 12:10 PM Joe Witt <joe.w...@gmail.com> wrote: > > > > > > > > > Mike, > > > > > > > > > > To your first paragraph then I interpret that to read the same > > > > > as my proposal intended to read. Can you please provide > > > > > specific wording > > > > changes > > > > > in the event your proposal differs. > > > > > > > > > > To your second paragraph those things are prudent generally and > > there is > > > > > nothing new that would require that guidance at this time. > > > > > > > > > > Thanks > > > > > > > > > > I wrote: > > > > > 1. Declare the NiFi 1.28.x line as the 'End of Life/End of Support' > > line. > > > > > This means we may still do periodic bug fixes or when > > possible/reasonable > > > > > bump vulnerable libs. But we will not be doing further > > analysis/triage > > > > of > > > > > security reports nor adding features. > > > > > > > > > > 2. Add a DISCLAIMER to the source and key binaries of the > > > > > 1.x/1.28 > > line > > > > > [1]. > > > > > > > > > > 3. Update the downloads page making the links for nifi source > > > > > and the > > > > main > > > > > nifi assembly of whatever is the latest NiFi 1.28.x release > > > > > there but clearly articulated as the end of support line for > > > > > which bug fixes > > and > > > > some > > > > > narrow dependency updates may occur. Advise users of the 1.x > > > > > line > > of the > > > > > importance of planning to migrate to the 2.x line. > > > > > > > > > > 4. Conduct a VOTE to codify this. > > > > > > > > > > 5. Conduct an Apache NiFi 1.28.1 release to pickle up (2) and > > > > > the bug > > > > fixes > > > > > already available. > > > > > > > > > > 6. As we gather more user input on things which are helpful to > > > > > them > > we > > > > > factor these into migration guidance/tooling as appropriate on > > > > > the > > 2.x > > > > > line. > > > > > > > > > > > > > > > > > > > > On Thu, Nov 7, 2024 at 10:03 AM Mike Thomsen > > > > > <mikerthom...@gmail.com > > > > > > > > wrote: > > > > > > > > > > > Alright. > > > > > > > > > > > > I would suggest we go with the basic concept of EOL sometime > > > > > > this > > year, > > > > > but > > > > > > phrase it more gently as End of Active Development with a > > > > > > focus on > > > > 1.28.1 > > > > > > and beyond being "transition support snapshots for NiFi 1.X." > > > > > > What > > we > > > > > want > > > > > > to convey is "we hear you, you need time, we'll try to help > > > > > > smooth > > this > > > > > > over where we can" to enterprise users. I think a commitment > > > > > > to at > > > > least > > > > > > trying to patch CVEs where possible for up to a year, provided > > there > > > > are > > > > > > volunteers, would be reasonable for us as an offer to meet > > > > > > users > > > > halfway. > > > > > > > > > > > > My guidance as an integrator to our security team would be to > > > > > > begin transitioning any instances that are public facing to be > > > > > > behind a > > VPN > > > > by > > > > > > the end of 2025 Q1, as that will effectively mitigate a lot of > > > > > > the > > > > > concerns > > > > > > raised up thread about Internet-related dangers to active NiFi > > > > > instances. I > > > > > > would also recommend that any systems that touch the API begin > > > > evaluating > > > > > > application-specific firewall rules and AWS security groups to > > ensure > > > > > that > > > > > > NiFi's REST APIs are accessible only to other applications > > > > > > that > > have > > > > been > > > > > > whitelisted. > > > > > > > > > > > > > > > > > > > > > > > > On Thu, Nov 7, 2024 at 11:18 AM Joe Witt <joe.w...@gmail.com> > > wrote: > > > > > > > > > > > > > Mike > > > > > > > > > > > > > > I hear you. > > > > > > > > > > > > > > As a PMC member please make a concrete proposal and offer > > > > > > > wording > > > > that > > > > > > you > > > > > > > think helps the community conduct its mission and the users > > benefit > > > > > from > > > > > > > it. > > > > > > > > > > > > > > Thanks > > > > > > > Joe > > > > > > > > > > > > > > On Thu, Nov 7, 2024 at 9:12 AM Mike Thomsen < > > mikerthom...@gmail.com> > > > > > > > wrote: > > > > > > > > > > > > > > > > it is always connected to external systems, and mostly > > exposed to > > > > > the > > > > > > > > Internet by connecting to many systems. > > > > > > > > > > > > > > > > Depending on what you mean by this, I think this could be > > > > > > > > a > > very > > > > bad > > > > > > > thing > > > > > > > > for a company akin to exposing something like Kibana > > > > > > > > without > > going > > > > > > > through > > > > > > > > a VPN. > > > > > > > > > > > > > > > > On Tue, Nov 5, 2024 at 3:00 PM ski n > > > > > > > > <raymondmees...@gmail.com > > > > > > > > wrote: > > > > > > > > > > > > > > > > > I think this is a good proposal. > > > > > > > > > > > > > > > > > > I would also like to share my experience as an > > > > > > > > > integration > > > > > consultant > > > > > > > > > implementing various integration systems for large > > enterprises. > > > > > > > > > > > > > > > > > > In general, these organizations are very conservative. > > > > > > > > > The > > > > > milestone > > > > > > > > > releases (like those for 2.0) are completely ignored. It > > doesn't > > > > > > matter > > > > > > > > if > > > > > > > > > they are already running in production in other > > organizations. > > > > The > > > > > > > first > > > > > > > > GA > > > > > > > > > release of a new major release isn't trusted either. > > > > > > > > > Only > > after a > > > > > > > couple > > > > > > > > of > > > > > > > > > minor releases and when there is a new long-term support > > release, > > > > > > they > > > > > > > > > start to think. > > > > > > > > > > > > > > > > > > Upgrading often disrupts day-to-day operations, business > > > > > > requirements, > > > > > > > > and > > > > > > > > > consumes resources. Only when an LTS arrives, the > > > > > > > > > pressure > > from > > > > the > > > > > > > > > security/dev team is high enough, the project budget is > > > > available, > > > > > it > > > > > > > > fits > > > > > > > > > into the company roadmap, and so on... does a > > migration/upgrade > > > > > > begin. > > > > > > > > With > > > > > > > > > thousands of flows and daily operations, all the > > > > > > > > > migration > > and > > > > > > > retesting > > > > > > > > > can take a long time. > > > > > > > > > > > > > > > > > > I think most organizations expect that version 1.x will > > > > > > > > > be > > > > > supported > > > > > > > for > > > > > > > > > many years, next to the new major that has just arrived. > > > > > > > > > I'm > > not > > > > > > saying > > > > > > > > > it's good, or possible, or safe, etc., but those are > > > > > > > > > just the > > > > > > timelines > > > > > > > > and > > > > > > > > > expectations in large organizations. Companies like > > Microsoft and > > > > > > > Oracle > > > > > > > > > understand this very well. They often offer (and charge > > > > > > > > > for) > > very > > > > > > long > > > > > > > > > timelines for their operating systems and software. > > > > > > > > > > > > > > > > > > An open source project relies mostly on other open > > > > > > > > > source > > > > projects. > > > > > > > These > > > > > > > > > may or may not have an EOL. The problem on top of this > > > > > > > > > with > > > > > > integration > > > > > > > > > software like NiFi is that, by its nature, it is always > > connected > > > > > to > > > > > > > > > external systems, and mostly exposed to the Internet by > > > > connecting > > > > > to > > > > > > > > many > > > > > > > > > systems. > > > > > > > > > > > > > > > > > > Thus make it very clear what the risks are, but still > > > > > > > > > offer > > bug > > > > > fixes > > > > > > > for > > > > > > > > > some time, is probably the best way forward. > > > > > > > > > > > > > > > > > > Raymond > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On Tue, Nov 5, 2024 at 8:31 PM Joe Witt > > > > > > > > > <joe.w...@gmail.com> > > > > > wrote: > > > > > > > > > > > > > > > > > > > To be actionable and concrete here is a proposal: > > > > > > > > > > > > > > > > > > > > 1. Declare the NiFi 1.28.x line as the 'End of > > > > > > > > > > Life/End of > > > > > Support' > > > > > > > > line. > > > > > > > > > > This means we may still do periodic bug fixes or when > > > > > > > > possible/reasonable > > > > > > > > > > bump vulnerable libs. But we will not be doing > > > > > > > > > > further > > > > > > > analysis/triage > > > > > > > > > of > > > > > > > > > > security reports nor adding features. > > > > > > > > > > > > > > > > > > > > 2. Add a DISCLAIMER to the source and key binaries of > > > > > > > > > > the > > > > > 1.x/1.28 > > > > > > > line > > > > > > > > > > [1]. > > > > > > > > > > > > > > > > > > > > 3. Update the downloads page making the links for nifi > > source > > > > and > > > > > > the > > > > > > > > > main > > > > > > > > > > nifi assembly of whatever is the latest NiFi 1.28.x > > > > > > > > > > release > > > > there > > > > > > but > > > > > > > > > > clearly articulated as the end of support line for > > > > > > > > > > which > > bug > > > > > fixes > > > > > > > and > > > > > > > > > some > > > > > > > > > > narrow dependency updates may occur. Advise users of > > > > > > > > > > the > > 1.x > > > > > line > > > > > > of > > > > > > > > the > > > > > > > > > > importance of planning to migrate to the 2.x line. > > > > > > > > > > > > > > > > > > > > 4. Conduct a VOTE to codify this. > > > > > > > > > > > > > > > > > > > > 5. Conduct an Apache NiFi 1.28.1 release to pickle up > > > > > > > > > > (2) > > and > > > > the > > > > > > bug > > > > > > > > > fixes > > > > > > > > > > already available. > > > > > > > > > > > > > > > > > > > > 6. As we gather more user input on things which are > > helpful to > > > > > them > > > > > > > we > > > > > > > > > > factor these into migration guidance/tooling as > > appropriate on > > > > > the > > > > > > > 2.x > > > > > > > > > > line. > > > > > > > > > > > > > > > > > > > > Thanks > > > > > > > > > > > > > > > > > > > > [1] > > > > > > > > > > https://eur03.safelinks.protection.outlook.com/?url=ht > > > > > > > > > > tps%3A%2F%2Fgithub.com%2Fapache%2Fnifi%2Fpull%2F9491&d > > > > > > > > > > ata=05%7C02%7Cisha.lamboo%40virtualsciences.nl%7Cf08b0 > > > > > > > > > > efbd80149d3cbd508dcff6d6c0f%7C21429da9e4ad45f99a6fcd12 > > > > > > > > > > 6a64274b%7C0%7C0%7C638666092667241553%7CUnknown%7CTWFp > > > > > > > > > > bGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik > > > > > > > > > > 1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=Wp2thWionlzpD5 > > > > > > > > > > syVAEAFc07e33b8uhOE%2FlXj%2F5xNMk%3D&reserved=0 > > > > > > > > > > > > > > > > > > > > On Tue, Nov 5, 2024 at 9:04 AM Joe Witt < > > joe.w...@gmail.com> > > > > > > wrote: > > > > > > > > > > > > > > > > > > > > > Team, > > > > > > > > > > > > > > > > > > > > > > I will start a discussion thread on the users list > > > > > > > > > > > so we > > can > > > > > hear > > > > > > > > more > > > > > > > > > > > inputs from them and from that perspective. > > > > > > > > > > > > > > > > > > > > > > This thread needs to focus on what the > > > > > > contributors/committers/PMC > > > > > > > in > > > > > > > > > the > > > > > > > > > > > community can/will/should do and the PMC in > > > > > > > > > > > particular as > > > > we're > > > > > > > > > obligated > > > > > > > > > > > to ensure we're putting out software for which we > > > > > > > > > > > can > > stand > > > > > > behind > > > > > > > > its > > > > > > > > > > > security posture. > > > > > > > > > > > > > > > > > > > > > > We do not need to get worried about customers. They > > > > > > > > > > > have > > > > > vendors > > > > > > > > that > > > > > > > > > > > support them. What we need to worry about and > > > > > > > > > > > continue > > to do > > > > > an > > > > > > > > > > excellent > > > > > > > > > > > job caring for is the apache nifi user base and we > > > > > > > > > > > need > > to > > > > > ensure > > > > > > > > they > > > > > > > > > > > don't have the belief that the NiFi 1.x line will be > > fixed in > > > > > the > > > > > > > > > > presence > > > > > > > > > > > of vulnerability reports. I'll ask on the users > > > > > > > > > > > list how > > > > folks > > > > > > > would > > > > > > > > > > like > > > > > > > > > > > us to communicate about the state of things. > > > > > > > > > > > > > > > > > > > > > > What I think we need to ask here is more in the > > > > > > > > > > > spirit of > > > > what > > > > > > this > > > > > > > > > > thread > > > > > > > > > > > was started about. When do we as a > > contributor/committer/PMC > > > > > > base > > > > > > > > want > > > > > > > > > > to > > > > > > > > > > > make it official in our own sense that we will not > > > > > > > > > > > be > > > > producing > > > > > > > > > releases > > > > > > > > > > > for the 1.x line? How we best communicate/help the > > > > > > > > > > > user > > base > > > > > > then > > > > > > > > > > follows > > > > > > > > > > > from that. Stated another way those who feel they > > > > > > > > > > > will > > be > > > > in a > > > > > > > good > > > > > > > > > > > position to do security reviews, vulnerability scans > > > > > > > > > > > and > > > > > > > remediation, > > > > > > > > > > > conduct releases for some period of time please > > > > > > > > > > > share > > what > > > > you > > > > > > > think > > > > > > > > > > you'll > > > > > > > > > > > be able to do and roughly for how long. > > > > > > > > > > > > > > > > > > > > > > Thanks > > > > > > > > > > > > > > > > > > > > > > On Tue, Nov 5, 2024 at 3:36 AM Pierre Villard < > > > > > > > > > > pierre.villard...@gmail.com> > > > > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > > > >> Hi all, > > > > > > > > > > >> > > > > > > > > > > >> While I think we could set an EOL date a bit > > > > > > > > > > >> further in > > the > > > > > > > future, > > > > > > > > it > > > > > > > > > > is > > > > > > > > > > >> important to keep in mind what EOL means. It only > > > > > > > > > > >> means > > we > > > > > won't > > > > > > > be > > > > > > > > > > >> providing security fixes / bug fixes through new > > releases. > > > > It > > > > > > does > > > > > > > > not > > > > > > > > > > >> mean that NiFi 1.x is gone. If that is a big > > > > > > > > > > >> concern for > > > > some > > > > > > > users > > > > > > > > > when > > > > > > > > > > >> running EOL software then we should remind those > > > > > > > > > > >> users > > that > > > > > > > they've > > > > > > > > > been > > > > > > > > > > >> doing it for 2+ years already when using NiFi 1.x > > (taking > > > > > Jetty > > > > > > as > > > > > > > > an > > > > > > > > > > >> example here). And Joe is definitely right when > > > > > > > > > > >> saying > > that > > > > we > > > > > > > have > > > > > > > > a > > > > > > > > > > >> smaller and smaller group of people willing to > > > > > > > > > > >> spend an > > > > > > extensive > > > > > > > > > amount > > > > > > > > > > >> of > > > > > > > > > > >> time taking care of PR/reviews, of release > > > > > > > > > > >> candidates, > > > > > > > > > > testing/validating > > > > > > > > > > >> RCs, etc, for the 1.x line. > > > > > > > > > > >> > > > > > > > > > > >> I also agree that, even if many users are already > > > > > > > > > > >> using > > > > NiFi 2 > > > > > > in > > > > > > > > > > >> production, many places have strict policies to not > > adopt a > > > > > new > > > > > > > > major > > > > > > > > > > >> release. I don't want to start a debate whether > > > > > > > > > > >> this is > > > > making > > > > > > > sense > > > > > > > > > or > > > > > > > > > > >> not > > > > > > > > > > >> but we know those rules exist in many places :) And > > > > > > > > > > >> the > > fact > > > > > > that > > > > > > > we > > > > > > > > > had > > > > > > > > > > >> milestone releases for one year is not going to be > > enough of > > > > > an > > > > > > > > > > argument. > > > > > > > > > > >> > > > > > > > > > > >> Given what we've seen in the past, we usually make > > > > > > > > > > >> a new > > > > > release > > > > > > > > > every 3 > > > > > > > > > > >> months or so. It's probably fair to assume a 2.1.0 > > release > > > > > will > > > > > > > > happen > > > > > > > > > > >> early next year. With that in mind, I tend to agree > > > > > > > > > > >> with > > > > > Michael > > > > > > > > > > >> suggesting > > > > > > > > > > >> an EOL date at the end of January (3 months from now). > > We > > > > > could > > > > > > > also > > > > > > > > > say > > > > > > > > > > >> that 1.28.1 will happen at this time and will be > > > > > > > > > > >> the > > last > > > > one > > > > > in > > > > > > > the > > > > > > > > > > >> community. > > > > > > > > > > >> > > > > > > > > > > >> Vendors have already announced support for NiFi 1.x > > > > > > > > > > >> for > > > > > multiple > > > > > > > > > > >> additional > > > > > > > > > > >> years so this approach follows what we see in other > > projects > > > > > > where > > > > > > > > > > >> extended > > > > > > > > > > >> support is only provided through paid options with > > specific > > > > > > > > companies. > > > > > > > > > > >> > > > > > > > > > > >> It is awesome to finally see 2.0 out and this > > > > > > > > > > >> decision > > will > > > > > help > > > > > > > > drive > > > > > > > > > > >> users to that new release, which is much better in > > > > > > > > > > >> so > > many > > > > > > ways... > > > > > > > > > > >> > > > > > > > > > > >> Thanks, > > > > > > > > > > >> Pierre > > > > > > > > > > >> > > > > > > > > > > >> > > > > > > > > > > >> Le mar. 5 nov. 2024 à 10:36, Isha Lamboo < > > > > > > > > > > isha.lam...@virtualsciences.nl> > > > > > > > > > > >> a > > > > > > > > > > >> écrit : > > > > > > > > > > >> > > > > > > > > > > >> > Hi all, > > > > > > > > > > >> > > > > > > > > > > > >> > I understand the reasons to declare an EOL > > > > > > > > > > >> > quickly, > > given > > > > > the > > > > > > > > > external > > > > > > > > > > >> > dependencies, but like Russell said before the > > > > > > > > > > >> > short > > > > notice > > > > > is > > > > > > > > going > > > > > > > > > > to > > > > > > > > > > >> > cause trouble with our bigger corporate > > > > > > > > > > >> > customers. It > > > > would > > > > > > have > > > > > > > > > been > > > > > > > > > > >> nice > > > > > > > > > > >> > to have the EOL date announced about a year ago, > > > > > > > > > > >> > even > > if > > > > it > > > > > > had > > > > > > > > > been a > > > > > > > > > > >> > provisional one. The more you can delay it now, > > > > > > > > > > >> > the > > less > > > > > > > > > credibility I > > > > > > > > > > >> (and > > > > > > > > > > >> > NiFi itself) lose :-\ > > > > > > > > > > >> > > > > > > > > > > > >> > I've been pushing since the first announcement of > > NiFi 2.0 > > > > > for > > > > > > > our > > > > > > > > > > >> > customers to prepare. The smaller NiFi instances > > > > > > > > > > >> > are > > all > > > > > > > prepared. > > > > > > > > > But > > > > > > > > > > >> > there are also big customers with hundreds of > > > > > > > > > > >> > flows > > that > > > > > > depend > > > > > > > on > > > > > > > > > > >> > variables and XML templates, and as you can > > > > > > > > > > >> > imagine > > this > > > > was > > > > > > > > never a > > > > > > > > > > >> > priority for them without either a NiFi 2.0 GA to > > move to > > > > or > > > > > > an > > > > > > > > > actual > > > > > > > > > > >> EOL > > > > > > > > > > >> > date to get security officers upping the priority. > > > > > > > > > > >> > > > > > > > > > > > >> > Now we have a GA release finally, but corporate > > > > > > > > > > >> > Q4 > > plans > > > > are > > > > > > set > > > > > > > > in > > > > > > > > > > >> stone > > > > > > > > > > >> > and Q1 2025 plans are already filling up. Telling > > > > > > > > > > >> > the > > > > > > customers' > > > > > > > > > > >> > development teams to upend their plans and tell > > > > > > > > > > >> > their > > > > > business > > > > > > > > > > >> customers to > > > > > > > > > > >> > forget deliveries because NiFi needs to be fixed > > > > > > > > > > >> > ASAP > > is > > > > > > > probably > > > > > > > > > not > > > > > > > > > > >> going > > > > > > > > > > >> > to fly and instead going to seriously dent NiFi's > > > > reputation > > > > > > and > > > > > > > > > > >> position. > > > > > > > > > > >> > Unless we can automate the flow migration process > > > > > > > > > > >> > it's > > > > going > > > > > > to > > > > > > > > be a > > > > > > > > > > >> > year-long migration at least. > > > > > > > > > > >> > > > > > > > > > > > >> > That said, are there any tools or scripts to make > > > > > > > > > > >> > the > > > > > > migration > > > > > > > > > > >> smoother? > > > > > > > > > > >> > Configuring multiple levels of parameter contexts > > > > > > > > > > >> > with > > > > > > > inheritance > > > > > > > > > is > > > > > > > > > > a > > > > > > > > > > >> > labor-intensive process if we are to mirror the > > current > > > > > setup > > > > > > > with > > > > > > > > > > >> > variables being inherited from main canvas, team > > > > > > > > > > >> > PG, > > > > subject > > > > > > PG > > > > > > > > and > > > > > > > > > > flow > > > > > > > > > > >> > PG, etc. Anything that could go through the > > > > > > > > > > >> > process > > groups > > > > > and > > > > > > > > > > configure > > > > > > > > > > >> > this automatically would be greatly appreciated. > > > > > > > > > > >> > I > > will > > > > look > > > > > > > into > > > > > > > > > that > > > > > > > > > > >> > myself too, but anything helps really. > > > > > > > > > > >> > > > > > > > > > > > >> > Regards, > > > > > > > > > > >> > > > > > > > > > > > >> > Isha > > > > > > > > > > >> > > > > > > > > > > > >> > -----Oorspronkelijk bericht----- > > > > > > > > > > >> > Van: Joe Witt <joe.w...@gmail.com> > > > > > > > > > > >> > Verzonden: maandag 4 november 2024 23:44 > > > > > > > > > > >> > Aan: dev@nifi.apache.org > > > > > > > > > > >> > Onderwerp: Re: [DISCUSS] End-of-life timing for > > > > > > > > > > >> > NiFi 1 > > > > > > > > > > >> > > > > > > > > > > > >> > The EOL discussion is not here because we have a > > > > > > > > > > >> > new > > > > > problem. > > > > > > > It > > > > > > > > is > > > > > > > > > > >> here > > > > > > > > > > >> > because we finally have an answer. > > > > > > > > > > >> > > > > > > > > > > > >> > The inability to address reported vulnerabilities > > > > > > > > > > >> > or > > > > > > fundamental > > > > > > > > end > > > > > > > > > > of > > > > > > > > > > >> > life status for key underlying components in the > > > > > > > > > > >> > 1.x > > line > > > > > is a > > > > > > > > > problem > > > > > > > > > > >> that > > > > > > > > > > >> > was fully recognized three years ago. > > > > > > > > > > >> > > > > > > > > > > > >> > In that time we created a plan for what NiFi 2.0 > > would be > > > > > and > > > > > > > how > > > > > > > > > we'd > > > > > > > > > > >> > manage both maintaining the 1.x line while > > > > > > > > > > >> > building > > to the > > > > > 2.x > > > > > > > GA. > > > > > > > > > In > > > > > > > > > > >> the > > > > > > > > > > >> > past year we've conducted four milestone releases > > > > > > > > > > >> > of > > NiFi > > > > > 2.x > > > > > > > and > > > > > > > > > > we've > > > > > > > > > > >> > continued putting out feature, bug fix, and > > > > > > > > > > >> > security > > > > > > improvement > > > > > > > > > > >> releases > > > > > > > > > > >> > of 1.x. > > > > > > > > > > >> > > > > > > > > > > > >> > Feature bearing releases of 1.x are no longer > > appropriate > > > > as > > > > > > 2.x > > > > > > > > is > > > > > > > > > > here > > > > > > > > > > >> > and GA and that was the plan all along. > > > > > > > > > > >> > > > > > > > > > > > >> > Bug fixes are still reasonable in spirit but you > > > > > > > > > > >> > need > > > > people > > > > > > to > > > > > > > > > submit > > > > > > > > > > >> the > > > > > > > > > > >> > JIRAs, fix the JIRAs, peer review the changes, > > > > > > > > > > >> > and to > > > > > conduct > > > > > > > > > releases > > > > > > > > > > >> and > > > > > > > > > > >> > make votes. That is in increasingly short supply > > > > > > > > > > >> > as > > it > > > > has > > > > > > been > > > > > > > > > quite > > > > > > > > > > >> the > > > > > > > > > > >> > task splitting attention across two major lines > > > > > > > > > > >> > and > > > > > naturally > > > > > > > > > > developers > > > > > > > > > > >> > and users will gravitate toward the go forward path. > > > > > > > > > > >> > > > > > > > > > > > >> > Vulnerability/Security related considerations are > > where > > > > > things > > > > > > > are > > > > > > > > > > >> > fundamentally problematic. We had a security > > > > > > > > > > >> > report > > today > > > > > > about > > > > > > > > the > > > > > > > > > > >> super > > > > > > > > > > >> > old/outdated front-end libraries we use in 1.x. > > > > > > > > > > >> > That > > > > won't > > > > > > > > change. > > > > > > > > > > We > > > > > > > > > > >> had > > > > > > > > > > >> > a report last week about Spring libraries needing > > updated > > > > > > except > > > > > > > > you > > > > > > > > > > >> can't > > > > > > > > > > >> > unless you have Pivotal support so not an option. > > Those > > > > > won't > > > > > > > > > change. > > > > > > > > > > >> We > > > > > > > > > > >> > have had questions around Jetty changes but that > > > > > > > > > > >> > is > > tied > > > > to > > > > > > Java > > > > > > > > 8. > > > > > > > > > > >> We've > > > > > > > > > > >> > had questions about Java 8 being end of life and > > > > > > > > > > >> > even > > Java > > > > > 11 > > > > > > > and > > > > > > > > > even > > > > > > > > > > >> now > > > > > > > > > > >> > Java 17 in terms of its codebase permissive > > > > > > > > > > >> > licensing > > > > > > changing. > > > > > > > > The > > > > > > > > > > >> things > > > > > > > > > > >> > we can reasonably address in the 1.x line are > > > > > > > > > > >> > getting > > > > > smaller > > > > > > > and > > > > > > > > > > >> smaller > > > > > > > > > > >> > and the time required to address any new thing is > > higher > > > > and > > > > > > > > higher. > > > > > > > > > > >> > > > > > > > > > > > >> > We as a community, regardless of good intentions, > > cannot > > > > fix > > > > > > the > > > > > > > > > > >> illities > > > > > > > > > > >> > of the 1.x line and thus the 2.x line is here. > > > > > > > > > > >> > The > > 1.x > > > > line > > > > > > > will > > > > > > > > > > >> > absolutely continue to atrophy and it will > > accelerate. If > > > > > we > > > > > > do > > > > > > > > not > > > > > > > > > > >> signal > > > > > > > > > > >> > EOL on 1.x that means we're saying we can keep > > > > > > > > > > >> > fixing > > > > > > problems. > > > > > > > > > While > > > > > > > > > > >> that > > > > > > > > > > >> > is true for bugs, that is not true for > > > > > > > > > > >> > vulnerabilities > > > > > broadly > > > > > > > and > > > > > > > > > for > > > > > > > > > > >> our > > > > > > > > > > >> > most critical components. > > > > > > > > > > >> > > > > > > > > > > > >> > If you still fix bugs people assume this means > > > > > > > > > > >> > you > > still > > > > > > > > reasonably > > > > > > > > > > fix > > > > > > > > > > >> > vulnerabilities/etc.. And unless we declare EOL > > > > > > > > > > >> > on > > the > > > > 1.x > > > > > > line > > > > > > > > we > > > > > > > > > > will > > > > > > > > > > >> > continue to get non-serviceable reports and > > > > > > > > > > >> > mislead > > the > > > > user > > > > > > > base. > > > > > > > > > > >> > > > > > > > > > > > >> > The answer is to clearly signal that users should > > > > transition > > > > > > to > > > > > > > > the > > > > > > > > > > 2.x > > > > > > > > > > >> > line and focus our help on answering questions > > > > > > > > > > >> > people > > > > might > > > > > > have > > > > > > > > on > > > > > > > > > > how > > > > > > > > > > >> to > > > > > > > > > > >> > do that. > > > > > > > > > > >> > > > > > > > > > > > >> > I am supportive of EOL for the 1.x line. I also > > > > > > > > > > >> > like > > the > > > > > > poetic > > > > > > > > > > nature > > > > > > > > > > >> of > > > > > > > > > > >> > the decade timing. > > > > > > > > > > >> > > > > > > > > > > > >> > On Mon, Nov 4, 2024 at 2:47 PM David Handermann < > > > > > > > > > > >> > exceptionfact...@apache.org> > > > > > > > > > > >> > wrote: > > > > > > > > > > >> > > > > > > > > > > > >> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
