[
https://issues.apache.org/jira/browse/CASSANDRA-19126?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17795254#comment-17795254
]
Berenguer Blasi commented on CASSANDRA-19126:
---------------------------------------------
I am a bit lost here. Let's go bit by bit:
I agree with [~jlewandowski] that we have a mess of CI yamls flying around and
mismatched configs produce errors. This seems to be the case for
{{SSTableLoaderEncryptionOptionsTest}} iiuc.
The upgrade process for SCM is described
[here|https://github.com/apache/cassandra/blob/trunk/conf/cassandra.yaml#L2129]
1. You start with SCM=4. No new features or formats enabled. If you're happy
with the binaries continue, else rollback.
2. Rolling upgrade to SCM= UPGRADING. While the cluster is in _mixed_ SCM new
features or formats should be enabled in a _safe & compatible_ way. Once the
_last_ node switches to UPGRADING do new features and formats fully kick in.
3. Rolling upgrade to NONE.
While nodes are in UPGRADING there is the extra cost of checking the SCM of the
other nodes so we know if can start using the new features/formats or not, i.e
[here|https://github.com/apache/cassandra/blob/cassandra-5.0/src/java/org/apache/cassandra/db/rows/Cell.java#L91]
for TTL. We switch to NONE to shed that cost and to protect from SCM flapping
if a node goes down and comes up again days later with the wrong config,
somebody copies an old yaml with the wrong SCM, some unintended node join, etc.
This makes the behavior of the cluster deterministic by config and protects
against accidents, doesn't rely on node topology which would be very dangerous
and fragile, etc.
So if streaming is indeed broken a test would be great to see how the code
plays out as my naive expectation is that this would all work like any other
std upgrade scenario. If it wasn't the case we'd need to hold off until all
nodes have been moved to UPGRADING.
> Streaming appears to be incompatible with different
> storage_compatibility_mode settings
> ---------------------------------------------------------------------------------------
>
> Key: CASSANDRA-19126
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19126
> Project: Cassandra
> Issue Type: Bug
> Components: Consistency/Streaming, Legacy/Streaming and Messaging,
> Messaging/Internode, Tool/bulk load
> Reporter: Branimir Lambov
> Assignee: Jacek Lewandowski
> Priority: Normal
> Fix For: 5.0-rc, 5.x
>
>
> In particular, SSTableLoader appears to be incompatible with
> storage_compatibility_mode: NONE, which manifests as a failure of
> {{org.apache.cassandra.distributed.test.SSTableLoaderEncryptionOptionsTest}}
> when the flag is turned on (found during CASSANDRA-18753 testing). Setting
> {{storage_compatibility_mode: NONE}} in the tool configuration yaml does not
> help (according to the docs, this setting is not picked up).
> This is likely a bigger problem as the acceptable streaming version for C* 5
> is 12 only in legacy mode and 13 only in none, i.e. two C* 5 nodes do not
> appear to be able to stream with each other if their setting for the
> compatibility mode is different.
--
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
