junrao commented on code in PR #21005:
URL: https://github.com/apache/kafka/pull/21005#discussion_r2800453384
##########
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:
@m1a2st : As @jsancio mentioned, the broker config validation logic may
require statically configured property specific to a broker, which is not
available in the controller. So, it's probably better to (1) leave the broker
config validation in the broker; (2) change the admin client to only send the
incrementalAlterConfig request with broker resource to the broker; (3) change
the controller to reject incrementalAlterConfig request with broker resource
directly from the client. There are also a few generic validations currently
only done in the broker like checking for dups, checking for null, checking for
valid resource type, etc. We probably can do those in both the broker and the
controller. Do those changes sound reasonable to you? If so, could you update
kip-1256 accordingly?
--
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]
