As a gut check, the idea of bundling a JRE with C* appeals to me from a "control your variables" perspective. Simplifies quite a bit of this problem imo.
On Wed, Mar 21, 2018 at 9:04 AM, Stefan Podkowinski <s...@apache.org> wrote: > There's also another option, which I just want to mention here for the > sake of discussion. > > Quoting the Oracle Support Roadmap: > "Instead of relying on a pre-installed standalone JRE, we encourage > application developers to deliver JREs with their applications." > > I've played around with Java 9 a while ago and also tested creating a > self contained JRE using jlink, which you can bundle and ship with your > application. So there's a technical solution for that with Java 9. Of > course you'd have to clarify licensing issues (OpenJDK is GPLv2 + > Classpath exception) first. > > Bundling a custom JRE along with Cassandra, would be convenient in a way > that we can do all the testing against the bundled Java version. We > could also switch to a new Java version whenever it fits us. Like e.g. > apache-cassandra-4.0.14_openjdk11u321 and two months later release > apache-cassandra-4.0.15_openjdk12u123. History has shown that planing > and timing new releases isn't always working out for us as expected. I'd > rather prefer not having to tightly coordinate our own releases together > with OpenJDK releases, if it can be avoided. At the same time I'd like > to avoid having users updating to incompatible JREs (think about > 8u161/#14173), or have them constantly ask which JRE version to use for > which Cassandra version, always with the risk of automatic updates > causing unexpected issues. Bundling the JRE may help us with that, as it > would become more a matter of testing and getting CI turn green, before > we're ready to bundle the next major JRE update, without getting the > user involved at all. > > If you would prefer using a global system JRE, that should still be > possible by installing an unbundled Cassandra version, but you'd have to > pay attention which Java version to use for which Cassandra release, > possibly having to provide patches and do some testing for more recent > Cassandra versions, in case of compatibility issues. If we update 3.11 > to Java 13 in mid 2019, we'd have to provide release candidates that can > be used for testing for such incompatibilities by LTS users and have > them provide patches, which then have to fully work with Java 13 of > course. Otherwise I can't see how to make Oracle/Redhat/IBM/Azul LTS > releases work, except on this best effort basis without official support > guarantees by us. > > I'm not too enthusiastic about this perspective. But I wouldn't > completely dismiss it either, without talking about all the other > options first. > > > On 20.03.2018 22:32, Ariel Weisberg wrote: >> Hi, >> >> Synchronizing with Oracle LTS releases is kind of low value if it's a paid >> offering. But if someone in the community doesn't want to upgrade and pays >> Oracle we don't want to get in the way of that. >> >> Which is how you end up with what Jordan and ElasticSearch suggest. I'm >> still +1 on that although in my heart of hearts I want to only support the >> latest OpenJDK on trunk and after we cut a release only change the JDK if >> there is a serious issue. >> >> It's going to be annoying once we have a serious security or correctness >> issue and we need to move to a later OpenJDK. The majority won't be paying >> Oracle for LTS. I don't think that will happen that often though. >> >> Regards, >> Ariel >> >> If that ends up not working and we find it's a problem to not be getting >> On Tue, Mar 20, 2018, at 4:50 PM, Jason Brown wrote: >>> Thanks to Hannu and others pointing out that the OracleJDK is a >>> *commercial* LTS, and thus not an option. mea culpa for missing the >>> "commercial" and just focusing on the "LTS" bit. OpenJDK is is, then. >>> >>> Stefan's elastic search link is rather interesting. Looks like they are >>> compiling for both a LTS version as well as the current OpenJDK. They >>> assume some of their users will stick to a LTS version and some will run >>> the current version of OpenJDK. >>> >>> While it's extra work to add JDK version as yet another matrix variable in >>> addition to our branching, is that something we should consider? Or are we >>> going to burden maintainers even more? Do we have a choice? Note: I think >>> this is similar to what Jeremiah is proposed. >>> >>> @Ariel: Going beyond 3 years could be tricky in the worst case because >>> bringing in up to 3 years of JDK changes to an older release might mean >>> some of our dependencies no longer function and now it's not just minor >>> fixes it's bringing in who knows what in terms of updated dependencies >>> >>> I'm not sure we have a choice anymore, as we're basically bound to what the >>> JDK developers choose to do (and we're bound to the JDK ...). However, if >>> we have the changes necessary for the JDK releases higher than the LTS (if >>> we following the elastic search model), perhaps it'll be a reasonably >>> smooth transition? >>> >>> On Tue, Mar 20, 2018 at 1:31 PM, Jason Brown <jasedbr...@gmail.com> wrote: >>> >>>> copied directly from dev channel, just to keep with this ML conversation >>>> >>>> 08:08:26 <snazy> Robert Stupp jasobrown: https://www.azul.com/java- >>>> stable-secure-free-choose-two-three/ and https://blogs.oracle.com/java- >>>> platform-group/faster-and-easier-use-and-redistribution-of-java-se >>>> 08:08:38 the 2nd says: "The Oracle JDK will continue as a commercial long >>>> term support offering" >>>> 08:08:46 also: http://www.oracle.com/technetwork/java/eol-135779.html >>>> 08:09:21 the keyword in that cite is "commercial" >>>> 08:21:21 <exlt> Michael Shuler a couple more thoughts.. 1) keep C* >>>> support in step with latest Ubuntu LTS OpenJDK major in main, 2) bundle JRE >>>> in C* releases? (JDK is not "legal" to bundle) >>>> 08:23:44 <spodkowinski> https://www.elastic.co/blog/elasticsearch- >>>> java-9-and-beyond - interesting read on that matter >>>> 08:26:04 can't wait for the infra and CI testing implications.. will be >>>> lot's of fun ;( >>>> 08:42:13 <snazy> Robert Stupp Not sure whether stepping with Ubuntu is >>>> necessary. It's not so difficult to update apt.source ;) >>>> 08:42:43 CI ? It just let's your test matrix explode - a litte ;) >>>> 08:46:48 <exlt> Michael Shuler yep, we currently `def jdkLabel = 'JDK 1.8 >>>> (latest)'` in job DSL and could easily modify that >>>> >>>> On Tue, Mar 20, 2018 at 9:08 AM, Kant Kodali <k...@peernova.com> wrote: >>>> >>>>> Java 10 is releasing today! >>>>> >>>>> On Tue, Mar 20, 2018 at 9:07 AM, Ariel Weisberg <ar...@weisberg.ws> >>>>> wrote: >>>>> >>>>>> Hi, >>>>>> >>>>>> +1 to what Jordan is saying. >>>>>> >>>>>> It seems like if we are cutting a release off of trunk we want to make >>>>>> sure we get N years of supported JDK out of it. For a single LTS >>>>> release N >>>>>> could be at most 3 and historically that isn't long enough and it's very >>>>>> likely we will get < 3 after a release is cut. >>>>>> >>>>>> Going beyond 3 years could be tricky in the worst case because bringing >>>>> in >>>>>> up to 3 years of JDK changes to an older release might mean some of our >>>>>> dependencies no longer function and now it's not just minor fixes it's >>>>>> bringing in who knows what in terms of updated dependencies. >>>>>> >>>>>> I think in some cases we are going to need to take a release we have >>>>>> already cut and make it work with an LTS release that didn't exist when >>>>> the >>>>>> release was cut. >>>>>> >>>>>> We also need to update how CI works. We should at least build and run a >>>>>> quick smoke test with the JDKs we are claiming to support and >>>>>> asynchronously run all the tests on the rather large matrix that now >>>>> exists. >>>>>> >>>>>> Ariel >>>>>> >>>>>> On Tue, Mar 20, 2018, at 11:07 AM, Jeremiah Jordan wrote: >>>>>>> My suggestion would be to keep trunk on the latest LTS by default, but >>>>>>> with compatibility with the latest release if possible. Since Oracle >>>>>>> LTS releases are every 3 years, I would not want to tie us to that >>>>>>> release cycle? >>>>>>> So until Java 11 is out that would mean trunk should work under Java >>>>> 8, >>>>>>> with the option of being compiled/run under Java 9 or 10. Once Java >>>>> 11 >>>>>>> is out we could then switch to 11 only. >>>>>>> >>>>>>> -Jeremiah >>>>>>> >>>>>>> On Mar 20, 2018, at 10:48 AM, Jason Brown <jasedbr...@gmail.com> >>>>> wrote: >>>>>>> >>>>>>>>>> Wouldn't that potentially leave us in a situation where we're >>>>> ready >>>>>> for >>>>>>>> a C* release but blocked waiting on a new LTS cut? >>>>>>>> >>>>>>>> Agreed, and perhaps if we're close enough to a LTS release (say >>>>> three >>>>>>>> months or less), we could choose to delay (probably with community >>>>>>>> input/vote). If we're a year or two out, then, no, we should not >>>>> wait. >>>>>> I >>>>>>>> think this is what I meant to communicate by "Perhaps we can >>>>> evaluate >>>>>> this >>>>>>>> over time." (poorly stated, in hindsight) >>>>>>>> >>>>>>>>> On Tue, Mar 20, 2018 at 7:22 AM, Josh McKenzie < >>>>> jmcken...@apache.org> >>>>>> wrote: >>>>>>>>> >>>>>>>>> Need a little clarification on something: >>>>>>>>> >>>>>>>>>> 2) always release cassandra on a LTS version >>>>>>>>> combined with: >>>>>>>>>> 3) keep trunk on the lasest jdk version, assumming we release a >>>>> major >>>>>>>>>> cassandra version close enough to a LTS release. >>>>>>>>> >>>>>>>>> Wouldn't that potentially leave us in a situation where we're ready >>>>>>>>> for a C* release but blocked waiting on a new LTS cut? For >>>>> example, if >>>>>>>>> JDK 9 were the currently supported LTS and trunk was on JDK 11, >>>>> we'd >>>>>>>>> either have to get trunk to work with 9 or wait for 11 to resolve >>>>>>>>> that. >>>>>>>>> >>>>>>>>>> On Tue, Mar 20, 2018 at 9:32 AM, Jason Brown < >>>>> jasedbr...@gmail.com> >>>>>> wrote: >>>>>>>>>> Hi all, >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> TL;DR Oracle has started revving the JDK version much faster, and >>>>> we >>>>>> need >>>>>>>>>> an agreed upon plan. >>>>>>>>>> >>>>>>>>>> Well, we probably should has this discussion this already by now, >>>>> but >>>>>>>>> here >>>>>>>>>> we are. Oracle announced plans to release updated JDK version >>>>> every >>>>>> six >>>>>>>>>> months, and each new version immediate supercedes the previous in >>>>> all >>>>>>>>> ways: >>>>>>>>>> no updates/security fixes to previous versions is the main thing, >>>>> and >>>>>>>>>> previous versions are EOL'd immediately. In addition, Oracle has >>>>>> planned >>>>>>>>>> parallel LTS versions that will live for three years, and then >>>>>> superceded >>>>>>>>>> by the next LTS; but not immediately EOL'd from what I can tell. >>>>>> Please >>>>>>>>> see >>>>>>>>>> [1, 2] for Oracle's offical comments about this change ([3] was >>>>>>>>>> particularly useful, imo), [4] and many other postings on the >>>>>> internet >>>>>>>>> for >>>>>>>>>> discussion/commentary. >>>>>>>>>> >>>>>>>>>> We have a jira [5] where Robert Stupp did most of the work to get >>>>> us >>>>>> onto >>>>>>>>>> Java 9 (thanks, Robert), but then the announcement of the JDK >>>>> version >>>>>>>>>> changes happened last fall after Robert had done much of the work >>>>> on >>>>>> the >>>>>>>>>> ticket. >>>>>>>>>> >>>>>>>>>> Here's an initial proposal of how to move forward. I don't suspect >>>>>> it's >>>>>>>>>> complete, but a decent place to start a conversation. >>>>>>>>>> >>>>>>>>>> 1) receommend OracleJDK over OpenJDK. IIUC from [3], the OpenJDK >>>>> will >>>>>>>>>> release every six months, and the OracleJDK will release every >>>>> three >>>>>>>>> years. >>>>>>>>>> Thus, the OracleJDK is the LTS version, and it just comes from a >>>>>> snapshot >>>>>>>>>> of one of those OpenJDK builds. >>>>>>>>>> >>>>>>>>>> 2) always release cassandra on a LTS version. I don't think we can >>>>>>>>>> reasonably expect operators to update the JDK every six months, on >>>>>> time. >>>>>>>>>> Further, if there are breaking changes to the JDK, we don't want >>>>> to >>>>>> have >>>>>>>>> to >>>>>>>>>> update established c* versions due to those changes, every six >>>>>> months. >>>>>>>>>> >>>>>>>>>> 3) keep trunk on the lasest jdk version, assumming we release a >>>>> major >>>>>>>>>> cassandra version close enough to a LTS release. Currently that >>>>> seems >>>>>>>>>> reasonable for cassandra 4.0 to be released with java 11 (18.9 >>>>> LTS) >>>>>>>>>> support. Perhaps we can evaluate this over time. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Once we agree on a path forward, *it is impreative that we publish >>>>>> the >>>>>>>>>> decision to the docs* so we can point contributors and operators >>>>>> there, >>>>>>>>>> instead of rehashing the same conversation. >>>>>>>>>> >>>>>>>>>> I look forward to a lively discussion. Thanks! >>>>>>>>>> >>>>>>>>>> -Jason >>>>>>>>>> >>>>>>>>>> [1] http://www.oracle.com/technetwork/java/eol-135779.html >>>>>>>>>> [2] >>>>>>>>>> https://blogs.oracle.com/java-platform-group/faster-and- >>>>>>>>> easier-use-and-redistribution-of-java-se >>>>>>>>>> [3] >>>>>>>>>> https://www.oracle.com/java/java9-screencasts.html?bcid= >>>>>>>>> 5582439790001&playerType=single-social&size=events >>>>>>>>>> [4] >>>>>>>>>> http://blog.joda.org/2018/02/java-9-has-six-weeks-to-live. >>>>>>>>> html?utm_source=feedburner&utm_medium=feed&utm_campaign=Feed%3A+ >>>>>>>>> StephenColebournesBlog+%28Stephen+Colebourne%27s+blog%29 >>>>>>>>>> [5] https://issues.apache.org/jira/browse/CASSANDRA-9608 >>>>>>>>> >>>>>>>>> ------------------------------------------------------------ >>>>> --------- >>>>>>>>> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org >>>>>>>>> For additional commands, e-mail: dev-h...@cassandra.apache.org >>>>>>>>> >>>>>>>>> >>>>>>> >>>>>>> --------------------------------------------------------------------- >>>>>>> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org >>>>>>> For additional commands, e-mail: dev-h...@cassandra.apache.org >>>>>>> >>>>>> >>>>>> --------------------------------------------------------------------- >>>>>> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org >>>>>> For additional commands, e-mail: dev-h...@cassandra.apache.org >>>>>> >>>>>> >>>>> >>>> >>>> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org >> For additional commands, e-mail: dev-h...@cassandra.apache.org >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org > For additional commands, e-mail: dev-h...@cassandra.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org For additional commands, e-mail: dev-h...@cassandra.apache.org
