mumrah commented on code in PR #12513:
URL: https://github.com/apache/kafka/pull/12513#discussion_r951824786
##########
metadata/src/main/java/org/apache/kafka/controller/FeatureControlManager.java:
##########
@@ -229,6 +243,12 @@ private ApiError updateMetadataVersion(
return invalidMetadataVersion(newVersionLevel, "Unknown
metadata.version.");
}
+ // We cannot set a version earlier than IBP_3_3_IV0, since that was
the first version that contained
+ // FeatureLevelRecord itself.
+ if (newVersion.isLessThan(minimumBootstrapVersion)) {
+ return invalidMetadataVersion(newVersionLevel, "Unable to set a
metadata.version less than " +
+ minimumBootstrapVersion);
+ }
Review Comment:
If we don't allow downgrading the flag, do we have a way of unsetting it?
If a downgraded broker comes up with 3.2, it will use whatever IBP is set to
determine its compatibility. The non-downgraded brokers could be using newer
replication protocols that the 3.2 broker doesn't support. In the IBP world, an
operator would first do a rolling downgrade of the IBP before lowering the
software version.
Another issue is registration. If the cluster is on 3.3 and
`metadata.version` is set to 3.3IV0 and a user wants to downgrade to 3.2, when
the first downgraded broker comes up it will register with an empty set of
features and the controller will infer (minSupported=3.0IV1,
maxSupported=3.0IV1) and reject the registration.
If we let the operator unset the `metadata.version`, we can let the absence
of the record infer 3.0IV1 in the cluster and then safely downgrade brokers.
Edit: considering 3.0-3.2 were pre-prod versions of KRaft, it's arguably
fine to make 3.3 a point of no return. If we decide to go this route we need to
include this in KIP-833
--
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: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
