junrao commented on code in PR #21005:
URL: https://github.com/apache/kafka/pull/21005#discussion_r2818558456
##########
core/src/main/scala/kafka/server/ConfigAdminManager.scala:
##########
@@ -112,48 +112,33 @@ class ConfigAdminManager(nodeId: Int,
})
request.resources().forEach(resource => {
if (!results.containsKey(resource)) {
- val resourceType = ConfigResource.Type.forId(resource.resourceType())
- val configResource = new ConfigResource(resourceType,
resource.resourceName())
- try {
- if (containsDuplicates(resource.configs().asScala.map(_.name()))) {
- throw new InvalidRequestException("Error due to duplicate config
keys")
- }
- val nullUpdates = new util.ArrayList[String]()
- resource.configs().forEach { config =>
- if (config.configOperation() != AlterConfigOp.OpType.DELETE.id() &&
- config.value() == null) {
- nullUpdates.add(config.name())
+ processConfigResource(
Review Comment:
> For example, if a broker cannot start up due to incorrect dynamic
configuration, we might want to correct the configuration via the controller
directly.
That's a valid point. One option is to continue allowing
incrementalAlterConfig to be issued directly to the controller to bypass the
broker specific validation. We just do the generic generic validations like
checking for dups, checking for null, checking for valid resource type, etc in
both the broker and the controller. What do you think @jsancio ?
--
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]
