...

Please keep the discussion on the mailing list rather than commenting on the wiki (wiki discussions get unwieldy fast).

Motivation

Currently, user/client configurations are stored in the Zookeeper. Brokers monitor the changes of these configurations from Zookeeper, and then enforce them in the process of each request. Any changes to the configurations have to talk to Zookeeper directly, which introduces more overhead for users. 

Given that we have released the KafkaAdminClient, which is capable of managing the configurations of brokers and topics for customers, it's desire to also support the configuration for users and clients. In this case, applications can leverage the unified KafkaAdminClient to manage their user/client configurations, instead of the direct dependency on Zookeeper. 

We already have support for the ACL managements in the AdminClient, and it would be straightforward to support the user/client config in the AdminClient as well.

...

the AdminClient supports a long list of APIs that can be leveraged by users in many different ways. For instance, the AdminClient allows users to manage entities such as topics, partitions, consumer offset, ACLs, replication log directories and so on. In these scenarios, users only need talk to brokers through AdminClient and there is no direct dependency between client applications and Zookeeper any more.

One missing piece in the AdminClient is the configuration of users and clientId entities, which causes some obstacles for users. For instance, there is no way for users to manage their produce/consume client quota through AdminClient. In addition, there is no support for users to manage any other user or clientId related properties through AdminClient in the future. In these scenarios, users have to direct communicate with Zookeeper, which is exactly the anti-AdminClient pattern.

Public Interfaces

The AdminClient has already defined the following configuration management APIs, the configuration of users and clientIds will reuse these two APIs.

public abstract class AdminClient implements AutoCloseable {

 public abstract DescribeConfigsResult describeConfigs(Collection<ConfigResource> resources, DescribeConfigsOptions options);

 public abstract AlterConfigsResult alterConfigs(Map<ConfigResource, Config> configs, AlterConfigsOptions options);

}

Currently we do not have configEntry defined for the user and client entities, so we propose to add them in the following packages:

...