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://github.com/apache/nifi/pull/9491 > > > > > > > > > > > > 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: > > > > > > >> > > > > > > > >> > > > > > > > > > > > > > > > > > > > > > > > > > > > >
