...
Brokers should be able to pull from a meta data store to get their configurations.
Status
Current state: "Under Discussion" Superseded by KIP-21
Discussion thread: here
JIRA: here
...
These changes use and are based on KAFKA-1845 (KafkaConfig should use ConfigDef).
Applying Global Configuration to the Broker
The new proposed workflow is the following:
...
The global configuration is stored in the same format as a topic-level configuration:
{ "version" : "1", "config" : {
"message.max.bytes" : "200000",
"num.network.threads" : "5"
}
} |
Dedicated zookeeper path to store global configuration: /brokers/config
Updating Global Configuration
To change global configuration the new Wire Protocol message is introduced. Proposed schema:
Request:
ConfigChangeRequest => [ConfigData] ConfigData => ConfigKey ConfigValue ConfigKey => string ConfigValue => string |
Response:
ConfigChangeResponse => ErrorCode ErrorCode => int16 |
To change global configuration:
- User issues ChangeConfigRequest to Controller with global configuration that needs to be updated
- Controller fetches current global configuration from zk, merges with supplied and validates merged config (this part relies on KAFKA-1845)
- If successful, configuration is updated in zk
- New global configuration is picked up by broker once restarted
Compatibility, Deprecation, and Migration Plan
- When will we remove the existing behavior?
I don't think we have to decide that nowIn 0.8.3 we will still support the property files but it will be deprecated and we will then remove support for property files in 0.9.0.
Rejected Alternatives
If there are alternative ways of accomplishing the same thing, what were they? The purpose of this section is to motivate why the design is the way it is and not some other way.