[
https://issues.apache.org/jira/browse/CASSANDRA-15234?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17127857#comment-17127857
]
Ekaterina Dimitrova commented on CASSANDRA-15234:
-------------------------------------------------
Thanks to a recent patch I managed to run the upgrade tests in CircleCI.
The [results
|https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/207/workflows/1d0a0a87-16d9-467b-9299-bb148cb10f68/jobs/1223]
look good(more than 700 failures but they are those which are currently
presented on trunk in CircleCI and mostly related to the environment) when we
use the old current DTest suite, CCM and cassandra.yaml. Using the old
cassandra.yaml is actually the way a real upgrade will happen.
In order to run the upgrade tests using the newly proposed version of the
DTests suite and CCM, I need to take care about a couple of places where the
suite checks for Cassandra version and tries respectively to load some of the
parameters with their new names which causes cluster start issues, preventing
some of the upgrade tests from run.
Currently identified the primary conflict to be in dtest_setup.py. After that
scripts is adjusted there are only around 20 tests which fail [here
|https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/206/workflows/1f7b0a54-c9e2-4305-8c94-be08d07846dd/jobs/1217/tests].
One of the other issues is the new name _materialized_views_enabled due_
{color:#172b4d}to which some of the cql tests fail.{color}
Quick intermediate solution to the mentioned problems would be to add a script
which:
1) runs before the upgrade tests start
2) replaces the new cassandra.yaml file with the old one
3) sets the names of the parameters which would cause issues to their old names
which as far as I see are 6-7 compared to almost 70 changed names according to
this patch.
Then I can open a follow-up ticket for fix of the tests so we don't use this
customization in the long term but I find this current issue as not being a
blocker for the patch or Beta.
*TO DO:* Update the Upgrade documentation with the steps of upgrading to
version 4 with the old cassandra.yaml and then updating the cassandra.yaml.
> Standardise config and JVM parameters
> -------------------------------------
>
> Key: CASSANDRA-15234
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15234
> Project: Cassandra
> Issue Type: Bug
> Components: Local/Config
> Reporter: Benedict Elliott Smith
> Assignee: Ekaterina Dimitrova
> Priority: Normal
> Fix For: 4.0-alpha
>
> Attachments: CASSANDRA-15234-3-DTests-JAVA8.txt
>
>
> We have a bunch of inconsistent names and config patterns in the codebase,
> both from the yams and JVM properties. It would be nice to standardise the
> naming (such as otc_ vs internode_) as well as the provision of values with
> units - while maintaining perpetual backwards compatibility with the old
> parameter names, of course.
> For temporal units, I would propose parsing strings with suffixes of:
> {{code}}
> u|micros(econds?)?
> ms|millis(econds?)?
> s(econds?)?
> m(inutes?)?
> h(ours?)?
> d(ays?)?
> mo(nths?)?
> {{code}}
> For rate units, I would propose parsing any of the standard {{B/s, KiB/s,
> MiB/s, GiB/s, TiB/s}}.
> Perhaps for avoiding ambiguity we could not accept bauds {{bs, Mbps}} or
> powers of 1000 such as {{KB/s}}, given these are regularly used for either
> their old or new definition e.g. {{KiB/s}}, or we could support them and
> simply log the value in bytes/s.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
