fvaleri commented on code in PR #14484:
URL: https://github.com/apache/kafka/pull/14484#discussion_r1346951770
##########
metadata/src/main/java/org/apache/kafka/controller/FeatureControlManager.java:
##########
@@ -344,7 +344,7 @@ private ApiError updateMetadataVersion(
log.warn("Downgrading metadata.version from {} to {}.",
currentVersion, newVersion);
} else if (allowUnsafeDowngrade) {
return invalidMetadataVersion(newVersionLevel, "Unsafe
metadata downgrade is not supported " +
- "in this version.");
+ "in this Kafka version.");
Review Comment:
Agree with both points. Should we log another Jira linked to KAFKA-13410 for
the missing functionality, which also includes updating the documentation?
##########
docs/upgrade.html:
##########
@@ -145,7 +145,7 @@ <h5><a id="upgrade_350_kraft"
href="#upgrade_350_kraft">Upgrading KRaft-based cl
</code>
</li>
<li>Note that the cluster metadata version cannot be downgraded to a
pre-production 3.0.x, 3.1.x, or 3.2.x version once it has been upgraded.
- However, it is possible to downgrade to production versions such
as 3.3-IV0, 3.3-IV1, etc.</li>
+ However, it is possible to downgrade to a backwards compatible
metadata version. The active Controller will block any incompatible downgrade
attempt.</li>
Review Comment:
I thought about that, but doesn't seem a great user experience. That said, I
don't see a better way, unless we want to create a new tool method to verify if
downgrade is possible between any two versions, and document it.
--
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: jira-unsubscr...@kafka.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
