THIS IS A TEST INSTANCE. ALL YOUR CHANGES WILL BE LOST!!!!
| Table of Contents |
|---|
Status
Current state: Under DiscussionAccepted
Discussion thread: Discussion, hereVoting
JIRA:
| Jira | ||||||
|---|---|---|---|---|---|---|
|
...
| Code Block | ||||
|---|---|---|---|---|
| ||||
bin/kafka-configs.sh --bootstrap-server localhost:9092 \
--entity-type brokers --entity-default \
--alter --add-config-file new.properties |
Input from STDIN can be used instead of a file on disk, to do this use a hyphen instead of a file path:
| Code Block | ||||
|---|---|---|---|---|
| ||||
grep 'code text
complex.property' server.properties | bin/kafka-configs --bootstrap-server localhost:9092 \
--entity-type brokers --entity-default \
--alter --add-config-file - |
Public Interfaces
We will add the --add-config-file option to kafka-configs.sh. It will be mutually exclusive with --add-config.
...
| Code Block | ||
|---|---|---|
| ||
bin/kafka-configs.sh --bootstrap-server localhost:9092 \
--entity-type brokers --entity-default \
--alter --add-config 'k1={"key1":"val1","key2":"val2"},k2=[[1,2],[3,4]]' |
...
| Code Block | ||
|---|---|---|
| ||
bin/kafka-configs.sh --bootstrap-server localhost:9092 \
--entity-type brokers --entity-default \
--alter \
--add-config k1=v1 \
--add-config k2=v1,v2,v3 \
--add-config k3=v3 \
--add-config 'k4={"key1": "val1", "key2": "val2"}' \
--add-config 'k5=[[1,2],[3,4]]' |
However this would break existing multi-key uses of kafka-configs.sh.
Allow configuration from STDIN as well as from a file
It might be nice to enable input from standard input, to enable pipe/grep workflows. However, it's not clear that such workflows would be common. A script that would use such a workflow can send the output of the pipe to a temporary file and load that instead. Since the rest of the commands in the Kafka CLI don't support specifying STDIN, we won't support that here either, for consistency. STDIN support across the entire toolset can be added as a separate KIP if the need arises.
| Expand | |||||||
|---|---|---|---|---|---|---|---|
| |||||||
Input from STDIN can be used instead of a file on disk, to do this use a hyphen instead of a file path:
|
Allow --add-config and --add-config-file at the same time
Instead of specifying that --add-config and --add-config-file are mutually exclusive, we could accept both. This creates ambiguity about what happens if a configuration is specified in both places. We could specify how this is resolved (eg. "keys values supplied in --add-config take precedence over keys over values supplied in the file"), but this seems more complex than is warranted. Users can call kafka-configs.sh multiple times if they want to add configs from multiple sources.
There is no similar ambiguity with --delete-config and --delete-config-file, since there's no value to conflict.
Include a --delete-config-file option
Some systems like Kubernetes allow the cleanup of resources by deleting with the same config that was used to create the resources. This is not an exactly parallel situation, because deleting a configuration property doesn't necessarily put the system in the same state that it was in before the addition.
| Expand | ||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| ||||||||||||||
So that the add and delete usages are parallel, we will also add an option to accept a properties file and delete the properties from the file. Any property defined in the file will be deleted, regardless of what value is defined in the file.
Input from STDIN can be used instead of a file on disk, to do this use a hyphen instead of a file path:
... We will add the |
Use a format other than a properties file for the configs
Since dynamic configurations are stored in ZooKeeper in JSON format, it might make sense to accept a JSON file in that same format. This seems like it is tying the implementation details too closely to the interface. Users already use properties files to specify configurations. Introducing a different format would add complexity.