squah-confluent commented on code in PR #23121:
URL: https://github.com/apache/kafka/pull/23121#discussion_r3858788473
##########
core/src/main/scala/kafka/server/ControllerConfigurationValidator.scala:
##########
@@ -39,6 +40,14 @@ import scala.collection.mutable
* the controller. Therefore, the validation here is just a kind of sanity
check, which
* should never fail under normal conditions.
*
+ * GROUP resources are validated here too, via {@link
GroupConfig#validateOnController}, even
+ * though the forwarding broker already performs the same full validation in
+ * {@link kafka.server.ConfigAdminManager#preprocess()} via {@link
GroupConfig#validateOnBroker}.
+ * This is kept, gated on {@code metadataVersion}, so that the cluster is
never left without GROUP
+ * config validation while it may still contain brokers that predate the
broker-side check
+ * (KAFKA-20790). It can be dropped once upgrading directly from a pre-{@link
MetadataVersion#IBP_4_5_IV0}
+ * cluster is no longer supported.
Review Comment:
* We're expressing the same information as the previous paragraph, but for
GROUPs. Copying the sentence structure makes it more obvious to the reader.
* We can leave the implementation details and removal considerations for
comments in the validation code.
```
* For changes to GROUP resources, the forwarding broker performs validation
in
* {@link kafka.server.ConfigAdminManager#preprocess()} before sending the
change to
* the controller. The validation here is only run when the cluster may
contain brokers
* that predate the broker-side validation.
```
--
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]
