Hey Colin, Thanks for the KIP!
It seems that the AlterConfigsResult is pretty much the same as ModifyConfigsResult. Instead of adding ModifyConfigs API and deprecating AlterConfigs API, would it be simpler to just add API alterConfigs( Map<ConfigResource, Config> changes, Set<ConfigResource> removals, final ModifyConfigsOptions options)? Currently we use the word "alter" in method names such as "alterReplicaLogDirs" and "alterCheckpointDir". So it is probably more preferred to keep using the word "alter" instead of "modify" if posssible. And if we can overload the alterConfigs(...) API to allow incremental change, it might make sense to keep the existing alterConfigs(Map<ConfigResource, Config> configs) for users who simply want to overwrite the entire configs. And those user would not have to make code change due to API deprecation. What do you think? Thanks, Dong On Wed, Jul 11, 2018 at 10:54 AM, Colin McCabe <cmcc...@apache.org> wrote: > Hi all, > > Previously, we discussed some issues with alterConfigs here on the mailing > list, and eventually came to the conclusion that the RPC as implemented > can't be used for a shell command modifying configurations. > > I wrote up a small KIP to fix the issues with the RPC. Please take a look > at https://cwiki.apache.org/confluence/display/KAFKA/KIP- > 339%3A+Create+a+new+ModifyConfigs+API > > best, > Colin >
