Status

Current state:  Discuss Accepted

Discussion thread: here

JIRA: KAFKA-2204

...

{"version" : 1, "config" : {"producer-_byte-_rate" : 1000, "consumer-_byte-_rate" : 2000}}

Config Change Notification

...

The notification data can be:
{"version" : 1, "entityTypeentity_type":"topic/client", "entityNameentity_name" : "topic_name/client_id"}

...

# Topic Commands - options are ported from TopicCommand.scala
bin/kafka.sh --alter-config --entityTypeentity-type [topic/client] --entity-entityNamename name --added-config key=value,key=value --deleted-config key,key,key --broker-list <host : port>
bin/kafka.sh --describe-config --entityTypeentity-type [topic/client] --entity-entityNamename name --broker-list <host : port>

...

• TopicConfigManager has a config_change_XX sequential znode under configs/. The format of data within the config_change node is going to change hence it is important to not make any config changes using TopicCommand until the cluster is fully upgraded. 
• We will eventually deprecate the tooling that changes entity configs by modifying znodes directly. All requests should be sensent to one of the brokers after KIP-4 is complete.

Migration plan for notifications

Since the format of notifications is going to change, the new code will no longer be able to read topic change notifications written in the older format. The purge interval for notifications is 15 minutes, so any notification older than 15 minutes should be ignored regardless of the content in the znode. In order to not lose any notifications, cluster administrators should not allow any config changes for at least 15 minutes prior to upgrading the cluster. Upon startup, the brokers will parse all notifications and purge the old ones. 
After the upgrade is complete, config changes cannot be done using tooling from older releases of Kafka.

If a rollback must be done after config changes have been made using the new format, the config changes must be purged from zookeeper prior to the rollback (since the old code will throw an exception if it reads a notification in the new format).

Rejected Alternatives

Dynamic Service Configs: After plenty of discussion, we've decided to not allow broker(service) configuration be dynamic. There were a couple of approaches:

...