adelapena commented on code in PR #2391:
URL: https://github.com/apache/cassandra/pull/2391#discussion_r1221527092
##########
src/java/org/apache/cassandra/config/DatabaseDescriptor.java:
##########
@@ -1424,9 +1425,20 @@ private static void
validateSSTableFormatFactories(Iterable<SSTableFormat.Factor
if (selectedFormat == null)
throw new ConfigurationException(String.format("Selected sstable
format '%s' is not available.", selectedFormatName));
+ validateWriteFormatVsStorageCompatibilityMode(selectedFormat,
getStorageCompatibilityMode());
+
return selectedFormat;
}
+ @VisibleForTesting
+ public static void
validateWriteFormatVsStorageCompatibilityMode(SSTableFormat<?, ?>
selectedFormat, StorageCompatibilityMode mode)
+ {
+ if (selectedFormat.name().equals(BtiFormat.NAME) && mode !=
StorageCompatibilityMode.NONE)
Review Comment:
`UPGRADING` allows testing a subset of the nodes with bti while keeping the
other nodes on big. And that composes with other features, like enabling other
version-dependant properties and tries on a subset of the nodes.
The original patch for bti was intended to work on the scenario described by
`UPGRADING`. What cases do you think might not work on a mixed cluster so that
bti should be disallowed until all nodes are upgraded?
Wouldn't that force users to go first to `big-oa` on a first restart with
`UPGRADING`, and then to `bti` on a second restart with `NONE`? If bti is
supported on `UPGRADING` upgrades could skip the `nc->oa` step.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: pr-unsubscr...@cassandra.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: pr-unsubscr...@cassandra.apache.org
For additional commands, e-mail: pr-h...@cassandra.apache.org
