...

Some users run controllers and brokers on the same machine (not containerized, but through tarballs, etc) and with ZooKeeper, they can independently start/stop the ZooKeeper controller and Kafka broker since there were specific shell scripts for each.

However in KRaft mode, they can't start and stop the KRaft controller independently from the Kafka broker. We need to provide a way for users to kill either controllers or brokers.

...

The command line for killing controllers/brokers with will change.

Instead of simply running 

./bin/kafka-server-stop.sh

• Binary log format

• The network protocol and api behavior

• Any class in the public packages under clientsConfiguration, especially client configuration

  • org/apache/kafka/common/serialization

  • org/apache/kafka/common

  • org/apache/kafka/common/errors

  • org/apache/kafka/clients/producer

  • org/apache/kafka/clients/consumer (eventually, once stable)

• Monitoring

• Command line tools and arguments

• Anything else that will likely break existing users in some way when they upgrade

Proposed Changes

The proposed change include adding an extra optional field "process-role", which specify the specific process the user want to kill, i.e, controller/broker. For example, the new command line to kill broker only will look like:

./bin/kafka-server-stop.sh --process-role broker

The output will indicate the process(es) that was(were) killed, and the process(es) that was(were) not killed, with the process PID. For example:

Killed broker with PID 69194
Skip killing controller with PID 69039

When a process-role field is not provided, the command line killed both controllers and brokers.

Proposed Changes

I'm changing the "kafka-server-stop.sh" file to accept an optional field process role. When the user specify a process role, I will retrieve the absolute path to the configuration file, and search for the value of "process role". If the process role from the configuration file matches the process role the user provided, that process will be killed, otherwise it will be skipped.

NOTE: If users want to use the feature, they have to provide an absolute path to the configuration file when starting a controller/broker process. Also, the configuration file has to be provided as the last argument. Describe the new thing you want to do in appropriate detail. This may be fairly extensive and have large subsections of its own. Or it may be a few sentences. Use judgement based on the scope of the change.

Compatibility, Deprecation, and Migration Plan

• What impact (if any) will there be on existing users?
• If we are changing behavior how will we phase out the older behavior?
• If we need special migration tools, describe them here.
• When will we remove the existing behavior?

Test Plan

Describe in few sentences how the KIP will be tested. We are mostly interested in system tests (since unit-tests are specific to implementation details). How will we know that the implementation works as expected? How will we know nothing broke?

Rejected Alternatives

Existing users won't need to change any behavior if they want to continue killing both controller/broker processes. Otherwise if they want to either broker/controller, they'll need to provide a process role field in the script language. 

Test Plan

The change can be tested through command line. 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.