[
https://issues.apache.org/jira/browse/CASSANDRA-18106?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17696091#comment-17696091
]
Michael Semb Wever commented on CASSANDRA-18106:
------------------------------------------------
bq. So I guess we consider people are on Java 8 upgrading from 3.11 to 4.1.
Then they switch to 11 and then they upgrade to 5? While we have only JAVA_HOME
how would we have such a complete test? I guess that was the past goal having
those separate JAVAX_HOME, no?
Yes very good point, you're 100% right [~e.dimitrova]. The matrix of upgrade
paths for the python dtests can be both multi-step (so long as the bounds are
adjacent major versions) and also forward upgrades (from the current branch
version to higher adjacent major versions). This (CASSANDRA-18285) illustrates
we can't use the same jdk for all tests in the one CI run, and we can't simply
select the '{{java.supported}}' jdk from the build.xml. We don't do forward
upgrades in the jvm-dtests.
You can see this in action
[here|https://ci-cassandra.apache.org/view/Cassandra%203.0/job/Cassandra-3.0/333/testReport/dtest-upgrade.upgrade_tests.cql_tests/]
(screenshot also attached).
I'm thinking this means that either we a) have some way of switching JDKs
inside the python dtest codebase (like it is today or some other approach), or
b) we run the python dtest upgrade tests twice and each run ignores (filters
out) upgrade paths that are not valid for the current JAVA_HOME jdk.
(a) maybe requires the least work, if we can limit JAVAn_HOME usage to dtest
python codebase and only use it on upgrade tests.
(b) has the advantage that we get the jdkX name in the tests names (because of
'{{testtag}}',
[ref|https://github.com/apache/cassandra/blob/d1e3c78/build.xml#L1132]), and
allows us to reduce code.
> Update CCM for JDK17 and revise current JDK detection strategy
> --------------------------------------------------------------
>
> Key: CASSANDRA-18106
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18106
> Project: Cassandra
> Issue Type: Task
> Components: CI
> Reporter: Ekaterina Dimitrova
> Assignee: Brandon Williams
> Priority: Normal
> Fix For: 4.x
>
> Attachments: Screenshot 2023-03-03 at 09.24.50.png
>
>
> As part of CASSANDRA-16895 initial POC an initial version of CCM patch was
> created. This needs to be revisited and reviewed
> Recently we closed CASSANDRA-18039 which brought questions, probably we need
> to revise how we detect JDK versions in CCM and whether it is correct. To the
> best of my knowledge there are certain tests in the repo around that and they
> pass so my guess is we need to revise just the strategy and maybe document it
> explicitly or consider if we want any changes to be applied. Also, we need to
> be careful with breaking changes.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
