[
https://issues.apache.org/jira/browse/CASSANDRA-19551?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17837534#comment-17837534
]
Berenguer Blasi commented on CASSANDRA-19551:
---------------------------------------------
Let's take a look and use
[this|https://ci-cassandra.apache.org/job/Cassandra-trunk/1859/#showFailuresLink
as baseline:
- distributed.test.log.FetchLogFromPeersTest: Timeout. Run locally and see if
it passes. Fails on baseline as well.
- fuzz.harry.integration.model.ConcurrentQuiescentCheckerIntegrationTest: Can't
help here but I don't think ccm plays a part.
- fuzz.ring.ConsistentBootstrapTest: Can't help here but I don't think ccm
plays a part.
- distributed.upgrade.ClusterMetadataUpgradeHarryTest: Can't help here but I
don't think ccm plays a part.
- distributed.test.log.FetchLogFromPeersTest: Timeout. Run locally and see if
it passes. Fails on baseline as well.
- fuzz.ring.ConsistentBootstrapTest: Timeout. Run locally and see if it passes
- distributed.upgrade.ClusterMetadataUpgradeHarryTest: Can't help here but I
don't think ccm plays a part.
- bootstrap_test.TestBootstrap: CASSANDRA-18098
- gossip_test.TestGossip: They fail on baseline and CASSANDRA-19538
- largecolumn_test.TestLargeColumn: Where do you see it failing consistenly?
-
upgrade_tests.upgrade_through_versions_test.TestProtoV3Upgrade_AllVersions_EndsAt_Trunk_HEAD:
Counters in upgrades are known problems CASSANDRA-19520
^If my checks are correct I don't think your PR introduces new failures. CI is
in a sorry state and I don't think we can do any better.
> CCM nodes share the same environment variable map breaking upgrade tests
> ------------------------------------------------------------------------
>
> Key: CASSANDRA-19551
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19551
> Project: Cassandra
> Issue Type: Bug
> Components: Test/dtest/python
> Reporter: Ariel Weisberg
> Assignee: Ariel Weisberg
> Priority: Normal
> Fix For: 5.x
>
> Attachments: ci_summary.html
>
>
> In {{node.py}} {{__environment_variables}} is generally always set with a map
> that is passed in from {{cluster.py}} so it is [shared between
> nodes](https://github.com/riptano/ccm/blob/ac264706c8ca007cc584871ce907d48db334d36d/ccmlib/node.py#L151)
> and if nodes modify the map, such as in {{start}} when [updating the Java
> version](https://github.com/riptano/ccm/blob/ac264706c8ca007cc584871ce907d48db334d36d/ccmlib/node.py#L860)
> then when {{get_env}} runs it will [overwrite the Java
> version](https://github.com/riptano/ccm/blob/ac264706c8ca007cc584871ce907d48db334d36d/ccmlib/node.py#L244)
> that is selected by {{update_java_version}}.
> This results in {{nodetool drain}} failing when upgrading from 3.11 to 4.0 in
> some of the upgrade tests because after the first node upgrades to 4.0 it's
> not longer possible for the subsequent nodes to select a Java version that
> isn't 11 because it's overridden by {{__environment_variables}}.
> I'm not even 100% clear on why the code in {{start}} should update
> {{__environment_variables}} at all if we calculate the correct java version
> on every invocation of other tools.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
