Agree with Mick on the revert, and agree w/you Jacek on this area needing to be cleaned up.
I'm just as irritated as anyone about how archaic and hard to trace our CI system is (trust me. The last 9 months has been... challenging), but with things like this that are effectively API's, the blast radius is wide and deep. It deserves a cleanup, but it needs conversations like this (I say as one of those people w/a downstream CI system that got busted by this change =/) The fact that we have CASSANDRA_USE_JDK11 in a world where we're supporting 17 and looking towards 21 is just... ugh. On Thu, May 23, 2024, at 6:22 AM, Mick Semb Wever wrote: >> When starting Cassandra nodes, CCM uses the current env Java distribution >> (defined by the JAVA_HOME env variable). This behavior is overridden in >> three cases: >> >> - Java version is not supported by the selected Cassandra distribution - in >> which case, CCM looks for supported Java distribution across JAVAx_HOME env >> variables >> >> - Java version is specified explicitly (--jvm-version arg or jvm_version >> param if used in Python) >> >> - CASSANDRA_USE_JDK11 is defined in env, in which case, for Cassandra 4.x >> CCM forces to use only JDK11 >> >> >> >> I want to ask you guys whether you are okay with removing the third >> exception. If we remove it, Cassandra 4.x will not be treated in any special >> way—CCM will use the current Java version, so if it is Java 11, it will use >> Java 11 (and automatically set CASSANDRA_USE_JDK11), and if it is Java 8, it >> will use Java 8 (and automatically unset CASSANDRA_USE_JDK11). >> >> >> >> I think there is no need for CCM to use CASSANDRA_USE_JDK11 to make a >> decision about which Java version to use as it adds more complexity, makes >> it work differently for Cassandra 4.x than for other Cassandra versions, and >> actually provides no value at all because if we work with Cassandra having >> our env configured for Java 11, we have to have CASSANDRA_USE_JDK11 and if >> not, we cannot have it. Therefore, CCM can be based solely on the current >> Java version and not include the existence of CASSANDRA_USE_JDK11 in the >> Java version selection process. >> >> >> WDYT? > > > With the recent commits to ccm we have now broken three different CI systems, > in numerous different ways. All remain broken. > > At this point in time, the default behaviour should be to revert those > commits. Not to discuss whether we can further remove existing functionality > on the assumption we know all consumers, or that they are all reading this > thread and agreeing. > > In ccm, the jdk selection and switching does indeed deserve a clean up. We > have found a number of superfluous ways of achieving the same thing that is > leading to unnecessary code complexity. But we should not be hard breaking > things for downstream users and our CI. > > The initial commit to ccm that broke things was to fix ccm running a binary > 5.0-beta1 with a particular jdk. This patch and subsequent fixes has > included additional refactoring/cleaning changes that have broken a number of > things, like jdk-switching and upgrade_through_versions tests. We keep > trying to fix each breakage, but are also including additional adjustments > "to do the right thing" that only ends up breaking yet another thing. This > shouldn't be how we apply changes to a library that has many (unknown) > consumers, nor that we don't have full test coverage on. > > Given the broken CI systems and the troubles we have already caused > consumers, my recommendation is that these commits are reverted, and we live > with the binary 5.0-beta1 breakage for now, while we more patiently work on a > more complete and thorough fix. Furthermore to the specific question in the > post, I don't believe we should be removing working functionality without > first a deprecation cycle, given that ccm has many unknown consumers. This > depreciation period can be time-based, since ccm doesn't have versions. > > > > > >
