...

grep 'complex.property' server.properties | bin/kafka-configs --bootstrap-server localhost:9092 \
  --entity-type brokers --entity-default \
  --alter --add-config-file -

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.

bin/kafka-configs --bootstrap-server localhost:9092 \
  --entity-type brokers --entity-default \
  --alter --delete-config-file old.properties

Input from STDIN can be used instead of a file on disk, to do this use a hyphen instead of a file path:

grep 'text
complex.property' server.properties | bin/kafka-configs --bootstrap-server localhost:9092 \
  --entity-type brokers --entity-default \
  --alter --adddelete-config-file -

Public Interfaces

We will add the --add-config-file option to kafka-configs.sh. It will be mutually exclusive with --add-config.

We will add the --delete-config-file option to kafka-configs.sh. It will not be mutually exclusive with --delete-config because there is no ambiguity about precedence.

Compatibility, Deprecation, and Migration Plan

...

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.

Use a format other than a properties file for the configs

...