...

This proposal attempts to build a unified mechanism for modeling configuration across various entities like topics, clients and brokers using Zookeeper.

Public Interfaces

• New Tooling We will add a new tool called ConfigChangeCommand that can manage all config changes in ZK. New methods will be added in AdminTools AdminUtils to change client and broker configuration. This will be similar to the topic config tooling already present.
• There will be new zookeeper paths under "config" but they are not considered to be public interfaces.

Proposed Changes

This proposal will reuse pieces of the TopicQuotaManager. Similar to topic configs, the proposal is to add a BrokerQuotaManager and ClientConfigManager. These classes will listen to Zk notifications from a certain path and apply the notifications within the brokers on a per-topic, broker or clientId basis. These approaches can share significant amounts of code amongst themselves. The only thing that is different is the entity that is being modeled and how the config changes are applied.

...

There should be 34 paths within config
/config/clientsproducers/<client_id>
/config/consumers/<client_id>
/config/topics/<topic_name>
/config/brokers/<broker_id>

Internally, the znodes are comma-separated key-value pairs where key represents the configuration to change.
{"version": x, "config" : {X1=Y1, X2=Y2..}

...

The properties in this znode are applicable to all clients, topics and brokers respectively. Changing something here should affect all entities unless overridden explicitly.
 
/config/producers/__default
/config/clientsconsumers/__default
/config/topics/__default
/config/brokers/__default
 
Let's extend the example of quotas. Assume that we have a default quota of 5Mbytes per second per producer and we want to change it to 10M for the producer Adi. The default znode will look like this:
/config/clientsproducers/__default
{"version": 0, "config" : {quota=5M}

/config/clientsproducers/Adi
{"version": 0, "config" : {quota=10M}

...