[jira] [Comment Edited] (CASSANDRA-18106) Update CCM for JDK17 and revise current JDK detection strategy
[ https://issues.apache.org/jira/browse/CASSANDRA-18106?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17846101#comment-17846101 ] Michael Semb Wever edited comment on CASSANDRA-18106 at 5/13/24 10:22 PM: -- We weren't running dtest-upgrade-large tests at all, so there was no need for jdk switching. (We'd forgotten about the --intensive flag on upgrade tests.) The tests in question are doing multi-step upgrades. (We don't recommend upgrading and switching jdk at the same time, here the absolutely correct thing for the tests to be doing is upgrading and then restarting to switch jdk, but that's kinda overkill.) Are these tests really testing something that is persisted (serialised), i.e. something that happens in 3.0 that persists and isn't a problem until two major version later in 5.0 ? That sounds more like serialisation tests (that don't even need to be upgrade tests). ccm still supports jdk switching with JAVAx_HOME env vars, so if we need to we can still introduce these vars carefully for just these particular tests found in dtest-upgrade-large. (i.e. there's no change to undo here, we're still moving forward to a cleaner place…) was (Author: michaelsembwever): We weren't running dtest-upgrade-large tests at all, so there was no need for jdk switching. (We'd forgotten about the --intensive flag on upgrade tests.) The tests in question are doing multi-step upgrades. (We don't recommend upgrading and switching jdk at the same time, here the absolutely correct thing for the tests to be doing is upgrading and then restarting to switch jdk, but that's kinda overkill.) Are these tests really testing something that is persisted (serialised), i.e. something that happens in 3.0 that persists and isn't a problem until two major version later in 5.0 ? That sounds more like serialisation tests (that don't even need to be upgrade tests). ccm still supports jdk switching with JAVAx_HOME env vars, so if we need to we can still introduce these vars carefully for just these particular tests found in dtest-upgrade-large. > 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: 5.0-alpha1, 5.0 > > 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
[jira] [Comment Edited] (CASSANDRA-18106) Update CCM for JDK17 and revise current JDK detection strategy
[ https://issues.apache.org/jira/browse/CASSANDRA-18106?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17846093#comment-17846093 ] Brandon Williams edited comment on CASSANDRA-18106 at 5/13/24 10:04 PM: Ah, that's right. I think this was a relevant bit: bq. 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. So we obviated the need to switch JDKs during a run by doing more runs with adjacent versions that share the same JDK. was (Author: brandon.williams): Ah, that's right. I think this was a relevant bit: > 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. So we obviated the need to switch JDKs during a run by doing more runs with adjacent versions that share the same JDK. > 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: 5.0-alpha1, 5.0 > > 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
[jira] [Comment Edited] (CASSANDRA-18106) Update CCM for JDK17 and revise current JDK detection strategy
[
https://issues.apache.org/jira/browse/CASSANDRA-18106?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17846089#comment-17846089
]
Ekaterina Dimitrova edited comment on CASSANDRA-18106 at 5/13/24 9:59 PM:
--
{quote}We do have tests that need to change jdks. The dtest-upgrade-large* test
types have tests like
upgrade_tests/upgrade_through_versions_test.py::TestProtoV3Upgrade_AllVersions_EndsAt_Trunk_HEAD
{quote}
I mentioned this back then, and if I remember correctly there was the argument
- we repeat test runs with the different branch upgrade test runs, we should
save resources?
If we consider change of jdks, we will be running the whole path when we run on
3.0, same on 3.11, same on 4.0, etc. Lots of repetition. Is this not an
argument anymore?
bq. Without the JAVAx_HOME variables set they skip steps that involve C*
versions that require a different jdk.
So this was intentional and those are not skipped when run with other branches
was (Author: e.dimitrova):
{quote}We do have tests that need to change jdks. The dtest-upgrade-large* test
types have tests like
upgrade_tests/upgrade_through_versions_test.py::TestProtoV3Upgrade_AllVersions_EndsAt_Trunk_HEAD
{quote}
I mentioned this back then, and if I remember correctly there was the argument
- we repeat test runs with the different branch upgrade test runs, we should
save resources?
If we consider change of jdks, we will be running the whole path when we run on
3.0, same on 3.11, same on 4.0, etc. Lots of repetition. Is this not an
argument anymore?
> 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: 5.0-alpha1, 5.0
>
> 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
[jira] [Comment Edited] (CASSANDRA-18106) Update CCM for JDK17 and revise current JDK detection strategy
[ https://issues.apache.org/jira/browse/CASSANDRA-18106?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17846085#comment-17846085 ] Brandon Williams edited comment on CASSANDRA-18106 at 5/13/24 9:50 PM: --- >From the comments it seems that both V3 and V4 will need to cross JDKs, and >probably someday V5 will too: \# Proto v3 upgrades (v3 is supported on 2.1, 2.2, 3.0, 3.11, 4.0, 4.1, trunk) \# Proto v4 upgrades (v4 is supported on 2.2, 3.0, 3.1, 4.0, 4.1, trunk) \# Proto v5 upgrades (v5 is supported on 4.1, trunk) It is unfortunate to discover this almost a year after an implementation relying on it not being true, but I guess we have no choice but to bring back JAVAx_HOME. was (Author: brandon.williams): >From the comments it seems that both V3 and V4 will need to cross JDKs, and >probably someday V5 will too: # Proto v3 upgrades (v3 is supported on 2.1, 2.2, 3.0, 3.11, 4.0, 4.1, trunk) # Proto v4 upgrades (v4 is supported on 2.2, 3.0, 3.1, 4.0, 4.1, trunk) # Proto v5 upgrades (v5 is supported on 4.1, trunk) It is unfortunate to discover this almost a year after an implementation relying on it not being true, but I guess we have no choice but to bring back JAVAx_HOME. > 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: 5.0-alpha1, 5.0 > > 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
[jira] [Comment Edited] (CASSANDRA-18106) Update CCM for JDK17 and revise current JDK detection strategy
[ https://issues.apache.org/jira/browse/CASSANDRA-18106?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17699829#comment-17699829 ] Ekaterina Dimitrova edited comment on CASSANDRA-18106 at 3/13/23 8:52 PM: -- As requested offline, I checked the CircleCI patches, they seem fine to me. Also, I took a quick look into the tests submitted and I didn't see any issues. Upgrade tests were not run, but if the CircleCI patches were the only change I do not expect surprises. Thank you. my +1 still stands was (Author: e.dimitrova): As requested offline, I checked the CircleCI patches, they seem fine to me. Also, I took a quick look into the tests submitted and I didn't see any issues. Upgrade tests were not run, but if the CircleCI patches were the only change I do not expect surprises. Thank you > 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: 5.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
[jira] [Comment Edited] (CASSANDRA-18106) Update CCM for JDK17 and revise current JDK detection strategy
[
https://issues.apache.org/jira/browse/CASSANDRA-18106?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17698960#comment-17698960
]
Ekaterina Dimitrova edited comment on CASSANDRA-18106 at 3/10/23 2:52 PM:
--
{quote}back down to 1448 tests
{quote}
Looks good to me, also correct JDK version from a quick look.
I don't think we should rerun other tests as the change that was affecting the
upgrade tests in the DTest repo (the bump 4.2 to 5.0) was affecting only
upgrade tests.
With this IMHO we can commit in the following order:
1) CCM patch + retag after that so that CI can pick up the latest commits
2) DTest patch
3) Cassandra patch (CASSANDRA-18293)
And with that we can close both this ticket and CASSANDRA-18293.
My suggestion is to send a message to the community to put on pause any commits
until those 3 are in to prevent any conflicts and confusion. WDYT?
Of course, all this said in case [~mck] being also a reviewer is still +1 after
the latest runs/changes
was (Author: e.dimitrova):
{quote}back down to 1448 tests
{quote}
Looks good to me, also correct JDK version from a quick look.
I don't think we should rerun other tests as the change that was affecting the
upgrade tests in the DTest repo (the bump 4.2 to 5.0) was affecting only
upgrade tests.
With this IMHO we can commit in the following order:
1) CCM patch + retag after that so that CI can pick up the latest commits
2) DTest patch
3) Cassandra patch (CASSANDRA-18293)
And with that we can close both this ticket and CASSANDRA-18293.
My suggestion is to send a message to the community to put on pause any commits
until those 3 are in to prevent any conflicts and confusion. WDYT?
Of course, all this said in case [~mck] is still +1 after the latest
runs/changes
> 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: 5.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
[jira] [Comment Edited] (CASSANDRA-18106) Update CCM for JDK17 and revise current JDK detection strategy
[ https://issues.apache.org/jira/browse/CASSANDRA-18106?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17698436#comment-17698436 ] Brandon Williams edited comment on CASSANDRA-18106 at 3/9/23 4:13 PM: -- We can remove jdk switching altogether, which I thought I did, but I missed that one. I've updated it and -am running again- it passed [here|https://app.circleci.com/pipelines/github/driftx/cassandra/901/workflows/30e2c354-80e9-4eb9-984f-e1f4629032e6/jobs/13076]. was (Author: brandon.williams): We can remove jdk switching altogether, which I thought I did, but I missed that one. I've updated it and am running again [here|https://app.circleci.com/pipelines/github/driftx/cassandra/901/workflows/30e2c354-80e9-4eb9-984f-e1f4629032e6/jobs/13076]. > 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: 5.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
[jira] [Comment Edited] (CASSANDRA-18106) Update CCM for JDK17 and revise current JDK detection strategy
[
https://issues.apache.org/jira/browse/CASSANDRA-18106?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17698421#comment-17698421
]
Ekaterina Dimitrova edited comment on CASSANDRA-18106 at 3/9/23 2:57 PM:
-
Maybe we look at different links?
I see
[here|https://app.circleci.com/pipelines/github/driftx/cassandra/901/workflows/c2bf3302-4eb4-4e70-95dc-2ce419ad56af/jobs/13028]
(took it from the last table, trunk
[j8|https://app.circleci.com/pipelines/github/driftx/cassandra/901/workflows/c2bf3302-4eb4-4e70-95dc-2ce419ad56af]
you posted earlier, maybe you have newer run):
{code:java}
test_parallel_upgrade failed and was not selected for rerun.
You need to set JAVA8_HOME to run these tests!{code}
was (Author: e.dimitrova):
Maybe we look at different links?
I see
[here|https://app.circleci.com/pipelines/github/driftx/cassandra/901/workflows/c2bf3302-4eb4-4e70-95dc-2ce419ad56af/jobs/13028]
(took it from the last table trunk
[j8|https://app.circleci.com/pipelines/github/driftx/cassandra/901/workflows/c2bf3302-4eb4-4e70-95dc-2ce419ad56af]
you posted earlier, maybe you have newer run):
{code:java}
test_parallel_upgrade failed and was not selected for rerun.
You need to set JAVA8_HOME to run these tests!{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: 5.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
[jira] [Comment Edited] (CASSANDRA-18106) Update CCM for JDK17 and revise current JDK detection strategy
[
https://issues.apache.org/jira/browse/CASSANDRA-18106?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17698421#comment-17698421
]
Ekaterina Dimitrova edited comment on CASSANDRA-18106 at 3/9/23 2:57 PM:
-
Maybe we look at different links?
I see
[here|https://app.circleci.com/pipelines/github/driftx/cassandra/901/workflows/c2bf3302-4eb4-4e70-95dc-2ce419ad56af/jobs/13028]
(took it from the last table trunk
[j8|https://app.circleci.com/pipelines/github/driftx/cassandra/901/workflows/c2bf3302-4eb4-4e70-95dc-2ce419ad56af]
you posted earlier, maybe you have newer run):
{code:java}
test_parallel_upgrade failed and was not selected for rerun.
You need to set JAVA8_HOME to run these tests!{code}
was (Author: e.dimitrova):
Maybe we look at different links?
I see
[here|https://app.circleci.com/pipelines/github/driftx/cassandra/901/workflows/c2bf3302-4eb4-4e70-95dc-2ce419ad56af/jobs/13028]
(took it from the last table trunk you posted, maybe you have newer run):
{code:java}
test_parallel_upgrade failed and was not selected for rerun.
You need to set JAVA8_HOME to run these tests!{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: 5.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
[jira] [Comment Edited] (CASSANDRA-18106) Update CCM for JDK17 and revise current JDK detection strategy
[
https://issues.apache.org/jira/browse/CASSANDRA-18106?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17698421#comment-17698421
]
Ekaterina Dimitrova edited comment on CASSANDRA-18106 at 3/9/23 2:56 PM:
-
Maybe we look at different links?
I see
[here|https://app.circleci.com/pipelines/github/driftx/cassandra/901/workflows/c2bf3302-4eb4-4e70-95dc-2ce419ad56af/jobs/13028]
(took it from the last table trunk you posted, maybe you have newer run):
{code:java}
test_parallel_upgrade failed and was not selected for rerun.
You need to set JAVA8_HOME to run these tests!{code}
was (Author: e.dimitrova):
Maybe we look at different links?
I see
[here|https://app.circleci.com/pipelines/github/driftx/cassandra/901/workflows/c2bf3302-4eb4-4e70-95dc-2ce419ad56af/jobs/13028]:
{code:java}
test_parallel_upgrade failed and was not selected for rerun.
You need to set JAVA8_HOME to run these tests!{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: 5.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
[jira] [Comment Edited] (CASSANDRA-18106) Update CCM for JDK17 and revise current JDK detection strategy
[ https://issues.apache.org/jira/browse/CASSANDRA-18106?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17698079#comment-17698079 ] Ekaterina Dimitrova edited comment on CASSANDRA-18106 at 3/8/23 9:08 PM: - Please run also the Python upgrade tests. I believe it is a good idea to run also at least trunk tests in Jenkins. My past experience makes me believe that until we have the build scripts in-tree used by both CI systems, such changes is better to be run in both CI systems as they very often surprise us with differences. Thank you in advance was (Author: e.dimitrova): Please run also the Python upgrade tests. I believe it is a good idea to run also at least trunk in Jenkins. My past experience makes me believe that until we have the build scripts in-tree used by both CI systems, such changes is better to be run in both CI systems as they very often surprise us with differences. Thank you in advance > 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: 5.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
[jira] [Comment Edited] (CASSANDRA-18106) Update CCM for JDK17 and revise current JDK detection strategy
[ https://issues.apache.org/jira/browse/CASSANDRA-18106?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17698079#comment-17698079 ] Ekaterina Dimitrova edited comment on CASSANDRA-18106 at 3/8/23 9:08 PM: - Please run also the Python upgrade tests. I believe it is a good idea to run also at least trunk tests in Jenkins. My past experience makes me believe that until we have the build scripts in-tree used by both CI systems, such changes is better to be run in both CI systems pre-commit as they very often surprise us with differences. Thank you in advance was (Author: e.dimitrova): Please run also the Python upgrade tests. I believe it is a good idea to run also at least trunk tests in Jenkins. My past experience makes me believe that until we have the build scripts in-tree used by both CI systems, such changes is better to be run in both CI systems as they very often surprise us with differences. Thank you in advance > 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: 5.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
[jira] [Comment Edited] (CASSANDRA-18106) Update CCM for JDK17 and revise current JDK detection strategy
[ https://issues.apache.org/jira/browse/CASSANDRA-18106?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17698079#comment-17698079 ] Ekaterina Dimitrova edited comment on CASSANDRA-18106 at 3/8/23 9:07 PM: - Please run also the Python upgrade tests. I believe it is a good idea to run also at least trunk in Jenkins. My past experience makes me believe that until we have the build scripts in-tree used by both CI systems, such changes is better to be run in both CI systems as they very often surprise us with differences. Thank you in advance was (Author: e.dimitrova): Please run also the Python upgrade tests. I believe it is a good idea to run also at least trunk in Jenkins. My past experience makes me believer that until we have the build scripts in-tree used by both CI systems, such changes is better to be run in both CI systems as they very often surprise us with differences. Thank you in advance > 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: 5.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
[jira] [Comment Edited] (CASSANDRA-18106) Update CCM for JDK17 and revise current JDK detection strategy
[
https://issues.apache.org/jira/browse/CASSANDRA-18106?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17696122#comment-17696122
]
Michael Semb Wever edited comment on CASSANDRA-18106 at 3/3/23 12:13 PM:
-
And separately, back to…
bq. CASSANDRA-18293 is targeting them in the circle config where they do have
effect; I would remove them as part of CASSANDRA-17869, or even another ticket
since that's going to require a docker push.
I've tested and confirmed that ci-cassandra.a.o needs and works without the
JAVAX_HOME envs set. That is, jdks 8, 11, and 17 all work. (Note these scripts
don't support compiling with one jdk and then running with a higher.)
Furthermore, we can work around the docker push by unsetting those envs in
{{cassandra-dtest-pytest.sh}} like
[this|https://github.com/thelastpickle/cassandra-builds/commit/66a8484059561a7381ae829b4a39a52fb9104ccc].
was (Author: michaelsembwever):
And separately, back to…
bq. CASSANDRA-18293 is targeting them in the circle config where they do have
effect; I would remove them as part of CASSANDRA-17869, or even another ticket
since that's going to require a docker push.
I've tested and confirmed that ci-cassandra.a.o needs and works without the
JAVAX_HOME envs set.
Furthermore, we can work around the docker push by unsetting those envs in
{{cassandra-dtest-pytest.sh}} like
[this|https://github.com/thelastpickle/cassandra-builds/commit/66a8484059561a7381ae829b4a39a52fb9104ccc].
> 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
[jira] [Comment Edited] (CASSANDRA-18106) Update CCM for JDK17 and revise current JDK detection strategy
[ https://issues.apache.org/jira/browse/CASSANDRA-18106?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17695910#comment-17695910 ] Ekaterina Dimitrova edited comment on CASSANDRA-18106 at 3/2/23 10:14 PM: -- Ok, thank you for confirming. So I see the case that we are also saving on resources that way. As you run tests on every version, you won't be repeating. What I mean - running the full test 3.11 to 5 and then the test 4 or 4.1 to 5, skipping the overlap and running only what you need. Looking into CASSANDRA-18285, I think you actually reminded me there that there is also the case of 4.0 to 4.1 with 11 residing on 4.0. Another layer of duplication? was (Author: e.dimitrova): Ok, thank you for confirming. So I see the case that we are also saving on resources that way. As you run tests on every version, you won't be repeating. What I mean - running the full test 3.11 to 5 and then the test 4 or 4.1 to 5, skipping the overlap and running only what you need. Looking into CASSANDRA-18285, I think you actually mentioned that there is also the case of 4.0 to 4.1 with 11 residing on 4.0. Another layer of duplication? > 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 > > > 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
[jira] [Comment Edited] (CASSANDRA-18106) Update CCM for JDK17 and revise current JDK detection strategy
[ https://issues.apache.org/jira/browse/CASSANDRA-18106?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17695896#comment-17695896 ] Ekaterina Dimitrova edited comment on CASSANDRA-18106 at 3/2/23 9:00 PM: - I am thinking - if we consider Java 8 breaking change, then I would expect we don't change JDKs but we test the paths with 8 and then when we remove 8, we test those that are capable of handling 11. Considering we agreed as a community to maintain three versions at a time (with exception for 3.0) this sounds almost already limiting to testing adjacent versions. But let's consider if those were 4, 5, 6 (ignore 4.1 for a moment which someone will say it is minor) and they all run with Java 11, we are not going to test the upgrade from 4 to 6? So the way I understand is that whatever is the common JDK version dictates to some extend the upgrade path. Our upgrade tests also follow the upgrade paths people will take. 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? To be able to exercise the whole path and not stop on certain version and separately test that version upgrade etc? Just trying to create a proper mental model and not to miss anything. As I fear I do miss something... was (Author: e.dimitrova): I am thinking - if we consider Java 8 breaking change, then I would expect we don't change JDKs but we test the paths with 8 and then when we remove 8, we test those that are capable of handling 11. Considering we agreed as a community to maintain three versions at a time (with exception for 3.0) this sounds almost already limiting to testing adjacent versions. But let's consider if those were 4, 5, 6 (ignore 4.1 for a moment which someone will say it is minor) and they all run with Java 11, we are not going to test the upgrade from 4 to 6? So the way I understand is that whatever is the common JDK version dictates to some extend the upgrade path. Our upgrade tests also follow the upgrade paths people will take. 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? To be able to exercise the whole path and not stop on certain version and separately test that version etc? Just trying to create a proper mental model and not to miss anything. > 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 > > > 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
[jira] [Comment Edited] (CASSANDRA-18106) Update CCM for JDK17 and revise current JDK detection strategy
[ https://issues.apache.org/jira/browse/CASSANDRA-18106?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17695702#comment-17695702 ] Michael Semb Wever edited comment on CASSANDRA-18106 at 3/2/23 12:55 PM: - Gotcha, _python upgrade dtest upgrade_ that are upgrading the jvm during the test… TIL. Are there really any tests that switch the jdk during the test…? and if so, why any longer? A quick search and I cannot find any such tests, and my vote is on not recommending to users (or supporting) switching both C* versions and JDK version on the same node restart (Operators should be de-risking by default, and it's also a significant requirement on us to test and support, as this ticket shows…). was (Author: michaelsembwever): Gotcha, _python upgrade dtest upgrade_ that are upgrading the jvm during the test… TIL. Are there really any tests that switch the jdk during the test…? and if so, why any longer? A quick search and I cannot find any such tests, and my vote is on not recommending to users (or supporting) switch C* versions and JDK version on the same node restart (Operators should be de-risking by default). > 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 > > > 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
[jira] [Comment Edited] (CASSANDRA-18106) Update CCM for JDK17 and revise current JDK detection strategy
[ https://issues.apache.org/jira/browse/CASSANDRA-18106?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17695702#comment-17695702 ] Michael Semb Wever edited comment on CASSANDRA-18106 at 3/2/23 12:54 PM: - Gotcha, _python upgrade dtest upgrade_ that are upgrading the jvm during the test… TIL. Are there really any tests that switch the jdk during the test…? and if so, why any longer? A quick search and I cannot find any such tests, and my vote is on not recommending to users (or supporting) switch C* versions and JDK version on the same node restart (Operators should be de-risking by default). was (Author: michaelsembwever): Gotcha, python dtest upgrade tests, that are upgrading the jvm during the test… TIL. Are there really any tests that switch the jdk during the test…? and if so, why any longer? A quick search and I cannot find any such tests, and my vote is on not recommending to users (or supporting) switch C* versions and JDK version on the same node restart (Operators should be de-risking by default). > 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 > > > 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
[jira] [Comment Edited] (CASSANDRA-18106) Update CCM for JDK17 and revise current JDK detection strategy
[ https://issues.apache.org/jira/browse/CASSANDRA-18106?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17695293#comment-17695293 ] Brandon Williams edited comment on CASSANDRA-18106 at 3/1/23 7:48 PM: -- CASSANDRA-18293 is targeting them in the circle config where they do have effect; I would remove them as part of CASSANDRA-17869, or even another ticket since that's going to require a docker push. was (Author: brandon.williams): CASSANDRA-18293 is targeting them in the circle config when they do have effect; I would remove them as part of CASSANDRA-17869, or even another ticket since that's going to require a docker push. > 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 > > > 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
[jira] [Comment Edited] (CASSANDRA-18106) Update CCM for JDK17 and revise current JDK detection strategy
[
https://issues.apache.org/jira/browse/CASSANDRA-18106?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17695172#comment-17695172
]
Ekaterina Dimitrova edited comment on CASSANDRA-18106 at 3/1/23 3:46 PM:
-
{quote}{color:#172b4d}Weird, because isn't that the same docker image we're
using in circleci ??{color}
{quote}
Yes, exporting those variables does not change anything here {_}I think{_}?
was (Author: e.dimitrova):
{quote}{quote} {color:#172b4d}Weird, because isn't that the same docker image
we're using in circleci ??{color}
{quote}{quote}
Yes, exporting those variables does not change anything here {_}I think{_}?
> 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
>
>
> 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
[jira] [Comment Edited] (CASSANDRA-18106) Update CCM for JDK17 and revise current JDK detection strategy
[
https://issues.apache.org/jira/browse/CASSANDRA-18106?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17695172#comment-17695172
]
Ekaterina Dimitrova edited comment on CASSANDRA-18106 at 3/1/23 3:45 PM:
-
{quote}{quote} {color:#172b4d}Weird, because isn't that the same docker image
we're using in circleci ??{color}
{quote}{quote}
Yes, exporting those variables does not change anything here {_}I think{_}?
was (Author: e.dimitrova):
{quote}bq. {color:#172b4d}Weird, because isn't that the same docker image we're
using in circleci ??{color}
{quote}
Yes, exporting those variables does not change anything here I think?
> 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
>
>
> 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
[jira] [Comment Edited] (CASSANDRA-18106) Update CCM for JDK17 and revise current JDK detection strategy
[
https://issues.apache.org/jira/browse/CASSANDRA-18106?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17695012#comment-17695012
]
Michael Semb Wever edited comment on CASSANDRA-18106 at 3/1/23 11:27 AM:
-
bq. Interesting, they
[failed|https://app.circleci.com/pipelines/github/driftx/cassandra/863/workflows/b154a40b-891a-42d4-9b4e-8e83db4881b3/jobs/12465/tests]
again.
I see in its
[logs|https://circleci.com/api/v1.1/project/github/driftx/cassandra/12556/output/106/0?file=true=63fe8dc3d05a281ea75445cf-0-build%2F781E9B7A]
that ccm is trying to start up with jdk8, not 11.
I pushed your branch and repeated this failure
[here|https://app.circleci.com/pipelines/github/michaelsembwever/cassandra/108/workflows/a84d9a40-2090-4844-a7ad-96490f17ebb5/jobs/4027].
When I removed all {{JAVA8_HOME}} and {{JAVA11_HOME}} env properties from the
circleci configs, it correctly runs ccm with jdk11 and fixed the tests, see
[here|https://app.circleci.com/pipelines/github/michaelsembwever/cassandra/109/workflows/f4206b43-b6b1-415b-944f-2015ab70ab1c/jobs/4029].
was (Author: michaelsembwever):
bq. Interesting, they
[failed|https://app.circleci.com/pipelines/github/driftx/cassandra/863/workflows/b154a40b-891a-42d4-9b4e-8e83db4881b3/jobs/12465/tests]
again.
I see in it's
[logs|https://circleci.com/api/v1.1/project/github/driftx/cassandra/12556/output/106/0?file=true=63fe8dc3d05a281ea75445cf-0-build%2F781E9B7A]
that ccm is trying to start up with jdk8, not 11.
I pushed your branch and repeated this failure
[here|https://app.circleci.com/pipelines/github/michaelsembwever/cassandra/108/workflows/a84d9a40-2090-4844-a7ad-96490f17ebb5/jobs/4027].
When I removed all {{JAVA8_HOME}} and {{JAVA11_HOME}} env properties from the
circleci configs, it correctly runs ccm with jdk11 and fixed the tests, see
[here|https://app.circleci.com/pipelines/github/michaelsembwever/cassandra/109/workflows/f4206b43-b6b1-415b-944f-2015ab70ab1c/jobs/4029].
> 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
>
>
> 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
[jira] [Comment Edited] (CASSANDRA-18106) Update CCM for JDK17 and revise current JDK detection strategy
[ https://issues.apache.org/jira/browse/CASSANDRA-18106?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17694778#comment-17694778 ] Ekaterina Dimitrova edited comment on CASSANDRA-18106 at 2/28/23 11:22 PM: --- What I noticed is that the number of failures is different between 30 and 40 so they are flaky tests. The issue is only with JDK11 but we didn't change the image, introducing newer JDK or the jolokia jar that the DTest repo comes with. I started digging further and I noticed you probably give rerun to the workflow from the UI? Is this correct? Could it be anything else get cached? I did another test now - pushed on my end a branch with your ccm repo and I ran into different problem: This was trying on an 11 build to run the tests with 8 - https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/2312/workflows/f7c3bf3f-b3f0-4ab0-82c8-408866dd363c/jobs/18973 This is your commit to your branches on latest trunk. Then on the same branch with trunk and the current ccm without your branch I didn't notice that problem: https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/2313/workflows/0df1adfb-bf74-4477-86d1-bb4830d8d697/jobs/18976 (I cancelled both builds but if you scroll through the steps) Can you try to trigger your branch by pushing empty commit? I think what you see is probably cached ccm maybe? was (Author: edimitrova): What I noticed is that the number of failures is different between 30 and 40 so they are flaky tests. The issue is only with JDK11 but we didn't change the image, introducing newer JDK or the jolokia jar that the DTest repo comes with. I started digging further and I noticed you probably give rerun to the workflow? Is this correct? Could it be anything else get cached? I did another test now - pushed on my end a branch with your ccm repo and I ran into different problem: This was trying on an 11 build to run the tests with 8 - https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/2312/workflows/f7c3bf3f-b3f0-4ab0-82c8-408866dd363c/jobs/18973 This is your commit to your branches on latest trunk. Then on the same branch with trunk and the current ccm without your branch I didn't notice that problem: https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/2313/workflows/0df1adfb-bf74-4477-86d1-bb4830d8d697/jobs/18976 (I cancelled both builds but if you scroll through the steps) Can you try to trigger your branch by pushing empty commit? I think what you see is probably cached ccm maybe? > 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 > > > 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
[jira] [Comment Edited] (CASSANDRA-18106) Update CCM for JDK17 and revise current JDK detection strategy
[ https://issues.apache.org/jira/browse/CASSANDRA-18106?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17694206#comment-17694206 ] Ekaterina Dimitrova edited comment on CASSANDRA-18106 at 2/27/23 10:27 PM: --- That is weird we had before that issue around not updating the branch on a second run. The issue you see now is different and also I can see it installed your branch >From Configure Virtual Environment and Python dependencies: -e git+[https://github.com/driftx/ccm.git@14f2434e94b39dd51032f88e90e054c1b89ff6e3#egg=ccm] Obtaining ccm from git+https://github.com/driftx/ccm.git@CASSANDRA-18106#egg=ccm (from -r /home/cassandra/cassandra-dtest/requirements.txt (line 13)) Cloning https://github.com/driftx/ccm.git (to revision CASSANDRA-18106) to ./env3.6/src/ccm Running command git clone --filter=blob:none -q https://github.com/driftx/ccm.git /home/cassandra/env3.6/src/ccm Running command git checkout -b CASSANDRA-18106 --track origin/CASSANDRA-18106 Switched to a new branch 'CASSANDRA-18106' Branch 'CASSANDRA-18106' set up to track remote branch 'CASSANDRA-18106' from 'origin'. Resolved https://github.com/driftx/ccm.git to commit 14f2434e94b39dd51032f88e90e054c1b89ff6e3 Preparing metadata (setup.py) ... - \ done I assume it is not CASSANDRA-18258 as your previous run that failed that way was when CASSANDRA-18258 it was still not committed. was (Author: e.dimitrova): That is weird we had before that issue around not updating the branch on a second run. The issue you see now is different and also I can see it installed your branch >From Configure Virtual Environment and Python dependencies: -e git+https://github.com/driftx/ccm.git@14f2434e94b39dd51032f88e90e054c1b89ff6e3#egg=ccm I assume it is not CASSANDRA-18258 as your previous run that failed that way was when CASSANDRA-18258 it was still not committed. > 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 > > > 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
[jira] [Comment Edited] (CASSANDRA-18106) Update CCM for JDK17 and revise current JDK detection strategy
[
https://issues.apache.org/jira/browse/CASSANDRA-18106?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17694206#comment-17694206
]
Ekaterina Dimitrova edited comment on CASSANDRA-18106 at 2/27/23 10:27 PM:
---
That is weird we had before that issue around not updating the branch on a
second run.
The issue you see now is different and also I can see it installed your branch
>From Configure Virtual Environment and Python dependencies:
-e
git+[https://github.com/driftx/ccm.git@14f2434e94b39dd51032f88e90e054c1b89ff6e3#egg=ccm]
{code:java}
Obtaining ccm from
git+https://github.com/driftx/ccm.git@CASSANDRA-18106#egg=ccm (from -r
/home/cassandra/cassandra-dtest/requirements.txt (line 13))
Cloning https://github.com/driftx/ccm.git (to revision CASSANDRA-18106) to
./env3.6/src/ccm
Running command git clone --filter=blob:none -q
https://github.com/driftx/ccm.git /home/cassandra/env3.6/src/ccm
Running command git checkout -b CASSANDRA-18106 --track origin/CASSANDRA-18106
Switched to a new branch 'CASSANDRA-18106'
Branch 'CASSANDRA-18106' set up to track remote branch 'CASSANDRA-18106' from
'origin'.
Resolved https://github.com/driftx/ccm.git to commit
14f2434e94b39dd51032f88e90e054c1b89ff6e3
Preparing metadata (setup.py) ... - \ done{code}
I assume it is not CASSANDRA-18258 as your previous run that failed that way
was when CASSANDRA-18258 it was still not committed.
was (Author: e.dimitrova):
That is weird we had before that issue around not updating the branch on a
second run.
The issue you see now is different and also I can see it installed your branch
>From Configure Virtual Environment and Python dependencies:
-e
git+[https://github.com/driftx/ccm.git@14f2434e94b39dd51032f88e90e054c1b89ff6e3#egg=ccm]
Obtaining ccm from
git+https://github.com/driftx/ccm.git@CASSANDRA-18106#egg=ccm (from -r
/home/cassandra/cassandra-dtest/requirements.txt (line 13))
Cloning https://github.com/driftx/ccm.git (to revision CASSANDRA-18106) to
./env3.6/src/ccm
Running command git clone --filter=blob:none -q
https://github.com/driftx/ccm.git /home/cassandra/env3.6/src/ccm
Running command git checkout -b CASSANDRA-18106 --track origin/CASSANDRA-18106
Switched to a new branch 'CASSANDRA-18106'
Branch 'CASSANDRA-18106' set up to track remote branch 'CASSANDRA-18106' from
'origin'.
Resolved https://github.com/driftx/ccm.git to commit
14f2434e94b39dd51032f88e90e054c1b89ff6e3
Preparing metadata (setup.py) ... - \ done
I assume it is not CASSANDRA-18258 as your previous run that failed that way
was when CASSANDRA-18258 it was still not committed.
> 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
>
>
> 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
[jira] [Comment Edited] (CASSANDRA-18106) Update CCM for JDK17 and revise current JDK detection strategy
[
https://issues.apache.org/jira/browse/CASSANDRA-18106?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17690832#comment-17690832
]
Ekaterina Dimitrova edited comment on CASSANDRA-18106 at 2/19/23 2:08 AM:
--
{quote} java.supported is providing "1.8" instead of just "8.
{quote}
Thanks for spotting it
{quote}Also, trivial, but can we remove the JAVAx_HOME lines (in just trunk):
{quote}
Honestly, we should also take care of CASSANDRA_USE_JDK11
[here|https://github.com/apache/cassandra/blob/trunk/.circleci/config.yml#L231]
or to be more accurate in config-2_1.yml and then use generate.sh to propagate
the change, etc
One more thing, CCM has its own tests and [JDK
tests|https://github.com/riptano/ccm/blob/master/tests/test_lib.py] also exist.
I know some of the CCM tests had some trouble to be run and Ariel has a
suggested fix that we keep on forgetting (published in CASSANDRA-17861) so
might be a good time to look at that one and then update here also the JDK CCM
tests accordingly.
was (Author: e.dimitrova):
{quote} java.supported is providing "1.8" instead of just "8.
{quote}
Thanks for spotting it
{quote}Also, trivial, but can we remove the JAVAx_HOME lines (in just trunk):
{quote}
Honestly, we should also take care of CASSANDRA_USE_JDK11
[here|https://github.com/apache/cassandra/blob/trunk/.circleci/config.yml#L231]
or to be more accurate in config-2_1.yml
One more thing, CCM has its own tests and [JDK
tests|https://github.com/riptano/ccm/blob/master/tests/test_lib.py] also exist.
I know some of the CCM tests had some trouble to be run and Ariel has a
suggested fix that we keep on forgetting (published in CASSANDRA-17861) so
might be a good time to look at that one and then update here also the JDK CCM
tests accordingly.
> 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
>
>
> 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
[jira] [Comment Edited] (CASSANDRA-18106) Update CCM for JDK17 and revise current JDK detection strategy
[ https://issues.apache.org/jira/browse/CASSANDRA-18106?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17690604#comment-17690604 ] Ekaterina Dimitrova edited comment on CASSANDRA-18106 at 2/17/23 9:24 PM: -- Please check here, 8 passes with 11: [https://app.circleci.com/pipelines/github/driftx/cassandra/863/workflows/7fde3481-a4fe-4dc3-87a5-85efe0444910/jobs/12336/steps] It is visible in step "Run dtests" Easy to miss, I did before so always checking since then :) I suspect you need to add 8 in the array maybe? was (Author: e.dimitrova): Please check here, 8 passes with 11: [https://app.circleci.com/pipelines/github/driftx/cassandra/863/workflows/7fde3481-a4fe-4dc3-87a5-85efe0444910/jobs/12336/steps] It is visible in step "Run dtests" Easy to miss, I did before so always checking since then :) > 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 > > > 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
[jira] [Comment Edited] (CASSANDRA-18106) Update CCM for JDK17 and revise current JDK detection strategy
[ https://issues.apache.org/jira/browse/CASSANDRA-18106?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17690604#comment-17690604 ] Ekaterina Dimitrova edited comment on CASSANDRA-18106 at 2/17/23 9:23 PM: -- Please check here, 8 passes with 11: [https://app.circleci.com/pipelines/github/driftx/cassandra/863/workflows/7fde3481-a4fe-4dc3-87a5-85efe0444910/jobs/12336/steps] It is visible in step "Run dtests" Easy to miss, I did before so always checking since then :) was (Author: e.dimitrova): Please check here, 8 passes with 11: [https://app.circleci.com/pipelines/github/driftx/cassandra/863/workflows/7fde3481-a4fe-4dc3-87a5-85efe0444910/jobs/12336/steps] It is visible in step "Under DTests" Easy to miss, I did before so always checking since then :) > 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 > > > 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
[jira] [Comment Edited] (CASSANDRA-18106) Update CCM for JDK17 and revise current JDK detection strategy
[
https://issues.apache.org/jira/browse/CASSANDRA-18106?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17690581#comment-17690581
]
Ekaterina Dimitrova edited comment on CASSANDRA-18106 at 2/17/23 8:51 PM:
--
{quote}+1
{quote}
I am lost considering our earlier conversation. +1 on the approach or +1 to
commit?
My understanding from the previous conversation in Slack is the current patch
will break Java 8 Python tests with trunk. So I am +1 on the patch, but not on
commit/retag yet as this will break trunk. Thank you
was (Author: e.dimitrova):
bq. +1
I am lost considering our earlier conversation. +1 on the approach or +1 to
commit?
My understanding is the current patch will break Java 8 Python tests with
trunk. So I am +1 on the patch, but not on commit/retag yet as this will break
trunk. Thank you
> 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
>
>
> 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
[jira] [Comment Edited] (CASSANDRA-18106) Update CCM for JDK17 and revise current JDK detection strategy
[ https://issues.apache.org/jira/browse/CASSANDRA-18106?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17690584#comment-17690584 ] Michael Semb Wever edited comment on CASSANDRA-18106 at 2/17/23 8:48 PM: - it won't break j8 on trunk source building ccm usage. so long as both JAVA_HOME and PATH is set to the jdk you want to use. was (Author: michaelsembwever): it won't break j8 on trunk source building ccm usage. so long as both JAVA_HOME and PATH is set to the jdk you want to use. > 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 > > > 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
[jira] [Comment Edited] (CASSANDRA-18106) Update CCM for JDK17 and revise current JDK detection strategy
[ https://issues.apache.org/jira/browse/CASSANDRA-18106?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17690561#comment-17690561 ] Michael Semb Wever edited comment on CASSANDRA-18106 at 2/17/23 8:48 PM: - +1 (EDIT: on the patch) was (Author: michaelsembwever): +1 > 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 > > > 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
[jira] [Comment Edited] (CASSANDRA-18106) Update CCM for JDK17 and revise current JDK detection strategy
[ https://issues.apache.org/jira/browse/CASSANDRA-18106?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17690581#comment-17690581 ] Ekaterina Dimitrova edited comment on CASSANDRA-18106 at 2/17/23 8:45 PM: -- bq. +1 I am lost considering our earlier conversation. +1 on the approach or +1 to commit? My understanding is the current patch will break Java 8 Python tests with trunk. So I am +1 on the patch, but not on commit/retag yet as this will break trunk. Thank you was (Author: e.dimitrova): +1 I am lost considering our earlier conversation. +1 on the approach or +1 to commit? My understanding is the current patch will break Java 8 Python tests with trunk. So I am +1 on the patch, but not on commit/retag yet as this will break trunk. Thank you > 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 > > > 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
[jira] [Comment Edited] (CASSANDRA-18106) Update CCM for JDK17 and revise current JDK detection strategy
[
https://issues.apache.org/jira/browse/CASSANDRA-18106?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17690581#comment-17690581
]
Ekaterina Dimitrova edited comment on CASSANDRA-18106 at 2/17/23 8:39 PM:
--
{quote}{quote}+1
{quote}{quote}
I am lost considering our earlier conversation. +1 on the approach or +1 to
commit?
My understanding is the current patch will break Java 8 Python tests with
trunk. So I am +1 on the patch but please, but not on commit/retag yet as this
will break trunk. Thank you
was (Author: e.dimitrova):
{quote}bq. +1
{quote}
I am lost considering our earlier conversation. +1 on the approach or +1 to
commit?
My understanding is the current patch will break Java 8 Python tests. So I am
+1 on the patch but please, but not on commit/retag yet as this will break
trunk. Thank you
> 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
>
>
> 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
[jira] [Comment Edited] (CASSANDRA-18106) Update CCM for JDK17 and revise current JDK detection strategy
[
https://issues.apache.org/jira/browse/CASSANDRA-18106?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17690581#comment-17690581
]
Ekaterina Dimitrova edited comment on CASSANDRA-18106 at 2/17/23 8:39 PM:
--
+1
I am lost considering our earlier conversation. +1 on the approach or +1 to
commit?
My understanding is the current patch will break Java 8 Python tests with
trunk. So I am +1 on the patch, but not on commit/retag yet as this will break
trunk. Thank you
was (Author: e.dimitrova):
{quote}{quote}+1
{quote}{quote}
I am lost considering our earlier conversation. +1 on the approach or +1 to
commit?
My understanding is the current patch will break Java 8 Python tests with
trunk. So I am +1 on the patch but please, but not on commit/retag yet as this
will break trunk. Thank you
> 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
>
>
> 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
[jira] [Comment Edited] (CASSANDRA-18106) Update CCM for JDK17 and revise current JDK detection strategy
[ https://issues.apache.org/jira/browse/CASSANDRA-18106?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17689350#comment-17689350 ] Brandon Williams edited comment on CASSANDRA-18106 at 2/15/23 9:31 PM: --- I have a branch in progress [here|https://github.com/driftx/ccm/tree/CASSANDRA-18106] that builds on Ekaterina's initial patch, and is enough to run the dtests without any errors that seem to be python's fault. It keys on '4.2' but this should continue to work after CASSANDRA-17973. The problem with not having CASSANDRA_USE_JDK17 is that 4.0 uses CASSANDRA_USE_JDK11 to adjust not just build versions, but [run versions as well|https://github.com/riptano/ccm/blob/master/ccmlib/common.py#L915], and JdkProperties only really indicates build versions. Currently, if you have CASSANDRA-18133, this patch will always use 17 because it appears in the supported versions. I'm not sure if we need a way to control this, or what the best way would be now. bq. I think we will need to push the CCM patch and the switch to JdkProperties one after another as otherwise we need to add intermediate code which sounds counter-productive to me If this patch doesn't find the supported versions from JdkProperties it will default to 11, so I think it should be safe to push first in that regard. was (Author: brandon.williams): I have a branch in progress [here|https://github.com/driftx/ccm/tree/CASSANDRA-18106] that builds on Ekaterina's initial patch, and is enough to run the dtests without any errors that seem to be python's fault. It keys on '4.2' but this should continue to work after CASSANDRA-17973. The problem with not having CASSANDRA_USE_JDK17 is that 4.0 uses CASSANDRA_USE_JDK11 to adjust not just build versions, but run versions as well, and JdkProperties only really indicates build versions. Currently, if you have CASSANDRA-18133, this patch will always use 17 because it appears in the supported versions. I'm not sure if we need a way to control this, or what the best way would be now. bq. I think we will need to push the CCM patch and the switch to JdkProperties one after another as otherwise we need to add intermediate code which sounds counter-productive to me If this patch doesn't find the supported versions from JdkProperties it will default to 11, so I think it should be safe to push first in that regard. > 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 > > > 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
[jira] [Comment Edited] (CASSANDRA-18106) Update CCM for JDK17 and revise current JDK detection strategy
[ https://issues.apache.org/jira/browse/CASSANDRA-18106?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17678871#comment-17678871 ] Ekaterina Dimitrova edited comment on CASSANDRA-18106 at 1/19/23 8:33 PM: -- We do not have CCM component so assigning it to CI. Assigning 4.x for fix version but if we see some issue with the JDK detection we might want to test any patches with the previous Cassandra versions too was (Author: e.dimitrova): We do not have CCM component so assigning it to CI. > 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 >Priority: Normal > Fix For: 4.x > > > 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
