[
https://issues.apache.org/jira/browse/CASSANDRA-14937?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16746451#comment-16746451
]
Benedict commented on CASSANDRA-14937:
--------------------------------------
Thanks for the quick review! Before I had even had a chance to post a comment
explaining the latest changes.
These are mostly excellent points, but a few quibbles:
{quote}it seems that IMessage doesn't have to be interface with each version
having it's own implementation
{quote}
This is necessary to support cross-version compatibility. There needs to be a
common parent that is shared across the class loaders, so that older versions
can access the contents of the newer messages (and vice versa)
{quote}new Object[][] here can be constant
{quote}
I deliberately chose not to do that here, since this is an uncommon code path,
it's test code, and it's unnecessary boilerplate. I don't mind changing if you
have a strong opinion on it though.
{quote}probably this will be documented, but "build" directory is currently
assumed to be under resources or?
{quote}
The build directory is in the project root, i.e. where {{ant dtest-jar}} writes
it. Probably this needs a wiki page or something documenting it, besides some
improved javadoc (that is in progress)
{quote}if you at 3.0 branch, you can't start 3.11 or 4.0 cluster because of
CDC. On the more general note. Since configs are generated from "cluster"
perspective (in AbstractCluster#create, we do not get to pick a right config
for the version.
{quote}
It's only intended to be backwards compatible, not forwards. Possibly you were
mislead by the UpgradeTest which may have been backported late last night after
extensive refactoring to the patch yesterday - I haven't yet cleaned up the
final touches of the various ports.
{quote}InstanceClassLoader#id is now unused
{quote}
As discussed on a previous JIRA, the idea of this was to aid in debugging. But
now we annotate the threads with the information, it's probably unnecessary, so
will remove it.
{quote}it looks like right now, to test current version
{quote}
No, you can already use the Versions.CURRENT public static final field, as is
used for the regular DistributedReadWritePathTest, but it's a TODO to
automatically include that in the Versions.find() (which currently only looks
for jars). Thanks for reminding me.
{quote}it looks like we can not create mixed-version cluster at the moment even
though nothing prevents it. Maybe it was planned for future? For example,
create a cluster with 3.0 and 4.0 without upgrades. I see quite a few use-cases
for that.
{quote}
I originally had planned to support that, but rolled back the decision since it
logically didn't seem to make much sense. We definitely don't support starting
a brand new cluster with a mixed version? We can reintroduce it if we want, but
it's fairly straight forward to stop/start the node with a new version too.
I'll address the other items you point out shortly.
> Multi-version In-JVM dtests
> ---------------------------
>
> Key: CASSANDRA-14937
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14937
> Project: Cassandra
> Issue Type: New Feature
> Components: Test/dtest
> Reporter: Benedict
> Assignee: Benedict
> Priority: Major
> Fix For: 2.2.x, 3.0.x, 3.11.x
>
>
> In order to support more sophisticated upgrade tests, including complex fuzz
> tests that can span a sequence of version upgrades, we propose abstracting a
> cross-version API for the in-jvm dtests. This will permit starting a node
> with an arbitrary compatible C* version, stopping the node, and restarting it
> with another C* version.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
