[
https://issues.apache.org/jira/browse/CASSANDRA-18499?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17744620#comment-17744620
]
Jacek Lewandowski edited comment on CASSANDRA-18499 at 7/19/23 1:42 PM:
------------------------------------------------------------------------
I don't think this is the correct fix for this problem.
{{upgrade_through_versions}} is not a regular upgrade test which is where we
test the ability to directly upgrade from version a to b. This test is
performing step-by-step upgrade 2.2 -> 3.0 -> 3.11 -> 4.0 -> 4.1 -> 5.0.
Removing the failing test cases does not fix the problem.
And the real problems are in the CI setup and one we fixed today in CCM. For
the CI setup, the problem is that 2.2, 3.0, and 3.11 will not run with Java
11+. If we run this test for Java 11 - 2.2, 3.0, and 3.11 should run with Java
8 regardless of the selected version. A similar situation will be running
upgrade tests with Java 17 when we want to verify the upgrade from 4.x running
with J8 or J11 to 5.0 running with J17.
This is caused by dropping envs {{{}JAVA8_HOME{}}}, {{{}JAVA11_HOME{}}}, and
{{{}JAVA17_HOME{}}}. CCM looks for those envs when selecting one of the
supported Java versions for the Cassandra version to be run. So even if we have
the default Java 11, when it runs Cassandra 3.0, which supports only Java 8, it
will look for JAVA8_HOME to use instead.
If you feel this will break something - I think that if you saw the problems,
they were caused by the CCM bug
https://issues.apache.org/jira/browse/CASSANDRA-18678, which caused to
disregard the default Java version even though it was supported. I tried the
{{upgrade_through_versions}} test full suite, that is 2.2 -> 5.0, with default
Java version 11, on the docker image, while keeping those envs set, and it all
worked fine. Didn't need to drop any test cases.
was (Author: jlewandowski):
I don't think this is the correct fix for this problem.
{{upgrade_through_versions}} is not a regular upgrade test which is where we
test the ability to directly upgrade from version a to b. This test is
performing step-by-step upgrade 2.2 -> 3.0 -> 3.11 -> 4.0 -> 4.1 -> 5.0.
Removing the failing test cases does not fix the problem.
And the real problems are in the CI setup and one we fixed today in CCM. For
the CI setup, the problem is that 2.2, 3.0, and 3.11 will not run with Java
11+. If we run this test for Java 11 - 2.2, 3.0, and 3.11 should run with Java
8 regardless of the selected version. A similar situation will be running
upgrade tests with Java 17 when we want to verify the upgrade from 4.x running
with J8 or J11 to 5.0 running with J17.
This is caused by dropping envs {{JAVA8_HOME}}, {{JAVA11_HOME}}, and
{{JAVA17_HOME}}. CCM looks for those envs when selecting one of the supported
Java versions for the Cassandra version to be run. So even if we have the
default Java 11, when it runs Cassandra 3.0, which supports only Java 8, it
will look for JAVA8_HOME to use instead.
If you feel this will break something - I think that if you saw the problems,
they were caused by the CCM bug
https://issues.apache.org/jira/browse/CASSANDRA-18678, which caused to
disregard the default Java version if it was supported. I tried the
{{upgrade_through_versions}} test full suite, that is 2.2 -> 5.0, with default
Java version 11, on the docker image, while keeping those envs set, and it all
worked fine. Didn't need to drop any test cases.
> Test Failure:
> upgrade_through_versions_test.py::TestUpgrade::test_rolling_upgrade_with_internode_ssl
> ----------------------------------------------------------------------------------------------------
>
> Key: CASSANDRA-18499
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18499
> Project: Cassandra
> Issue Type: Bug
> Components: Test/dtest/python
> Reporter: Andres de la Peña
> Assignee: Michael Semb Wever
> Priority: Normal
> Fix For: 5.x
>
>
> The upgrade Python dtest
> {{upgrade_through_versions_test.py::TestUpgrade::test_rolling_upgrade_with_internode_ssl}}
> seems to fail on CircleCI at least for trunk:
> *
> [https://app.circleci.com/pipelines/github/adelapena/cassandra/2882/workflows/b9abc2b2-2e79-47b2-b7ce-c549e75293bc/jobs/42698/tests]
> {code:java}
> self =
> <upgrade_tests.upgrade_through_versions_test.TestProtoV3Upgrade_AllVersions_EndsAt_Trunk_HEAD
> object at 0x7f89fc0f17f0>
> @pytest.mark.timeout(3000)
> def test_rolling_upgrade_with_internode_ssl(self):
> """
> Rolling upgrade test using internode ssl.
> """
> > self.upgrade_scenario(rolling=True, internode_ssl=True)
> upgrade_tests/upgrade_through_versions_test.py:371:
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
> _
> self =
> <upgrade_tests.upgrade_through_versions_test.TestProtoV3Upgrade_AllVersions_EndsAt_Trunk_HEAD
> object at 0x7f89fc0f17f0>
> populate = True, create_schema = True, rolling = True, after_upgrade_call = ()
> internode_ssl = True
> def upgrade_scenario(self, populate=True, create_schema=True,
> rolling=False, after_upgrade_call=(), internode_ssl=False):
> # Record the rows we write as we go:
> if populate:
> self.prepare()
> self.row_values = set()
> cluster = self.cluster
> if cluster.version() >= '3.0':
>
> cluster.set_configuration_options({'enable_user_defined_functions': 'true',
>
> 'enable_scripted_user_defined_functions': 'true'})
> elif cluster.version() >= '2.2':
>
> cluster.set_configuration_options({'enable_user_defined_functions': 'true'})
>
> if internode_ssl:
> logger.debug("***using internode ssl***")
> generate_ssl_stores(self.fixture_dtest_setup.test_path)
>
> self.cluster.enable_internode_ssl(self.fixture_dtest_setup.test_path)
>
> if populate:
> # Start with 3 node cluster
> logger.debug('Creating cluster (%s)' %
> self.test_version_metas[0].version)
> cluster.populate(3)
> [node.start(use_jna=True, wait_for_binary_proto=True) for node in
> cluster.nodelist()]
> else:
> logger.debug("Skipping cluster creation (should already be
> built)")
>
> # add nodes to self for convenience
> for i, node in enumerate(cluster.nodelist(), 1):
> node_name = 'node' + str(i)
> setattr(self, node_name, node)
>
> if create_schema:
> if rolling:
> self._create_schema_for_rolling()
> else:
> self._create_schema()
> else:
> logger.debug("Skipping schema creation (should already be built)")
>
> self._log_current_ver(self.test_version_metas[0])
>
> if rolling:
> # start up processes to write and verify data
> write_proc, verify_proc, verification_queue =
> self._start_continuous_write_and_verify(wait_for_rowcount=5000)
>
> # upgrade through versions
> for version_meta in self.test_version_metas[1:]:
> if version_meta.family > '3.11' and internode_ssl:
> seeds =[]
> for seed in cluster.seeds:
> > seeds.append(seed.ip_addr + ':7001')
> E AttributeError: 'str' object has no attribute
> 'ip_addr'
> upgrade_tests/upgrade_through_versions_test.py:422: AttributeError
> {code}
> I haven't seen this failure on Jenkins yet.
--
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
