...

Current state: Under Discussion

Discussion thread: here [Change the link from the KIP proposal email archive to your own email thread] 

JIRA: here [Change the link from KAFKA-1 to your own ticket]

Please keep the discussion on the mailing list rather than commenting on the wiki (wiki discussions get unwieldy fast).

Motivation

Describe the problems you are trying to solve.

Public Interfaces

Briefly list any new interfaces that will be introduced as part of this proposal or any existing interfaces that will be removed or changed. The purpose of this section is to concisely call out the public contract that will come along with this feature.

A public interface is any change to the following:

• 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

...

Summary

Add a new tool action, --cancel-all, to kafka-reassign-partitions that cancels all ongoing inter-broker partition reassignment in the cluster without requiring a reassignment JSON file.

The existing --cancel action remains unchanged and continues to support:

• JSON-scoped cancellation
• intra-broker log_dirs movement cancellation
• throttle cleanup behavior driven by the provided reassignment JSON

Motivation

Operators often need to stop all in-flight replica reassignments quickly—for example during an incident, a bad rollout, or when the original reassignment JSON is missing or out of date.

Today, the practical workflow is:

1. Call ListPartitionReassignments for the full cluster
2. Build an AlterPartitionReassignments request with replicas = null for each in-flight partition
3. Execute the request manually or through ad-hoc scripts

This workflow is:

• error-prone
• operationally slow under pressure
• difficult to execute safely when many topics are involved

The cluster already exposes the authoritative set of in-flight reassignments. The CLI should therefore provide a single, well-defined operation for the common case of cancelling all ongoing inter-broker partition reassignments.

Public Interfaces

CLI (kafka-reassign-partitions.sh)

--cancel-all becomes an additional top-level action alongside:

• --execute
• --verify
• --generate
• --cancel
• --list

Exactly one action may be specified per invocation, consistent with existing CLI behavior.

Proposed Changes

New Action: --cancel-all

The new action performs the following steps:

1. Fetch all ongoing partition reassignments using:
   • AdminClient.listPartitionReassignments()
2. Filter reassignments where:
   • addingReplicas or removingReplicas is non-empty
3. Submit cancellation requests using:
   • AdminClient.alterPartitionReassignments(... Optional.empty())

This provides a cluster-wide cancellation mechanism for inter-broker reassignments.

Behavior and Semantics

1. Scope: Cluster-wide inter-broker partition reassignments only (same notion as “ongoing” in ListPartitionReassignments when adding/removing is non-empty).
2. Log directories: --cancel-all does not cancel ongoing AlterReplicaLogDirs / log_dirs moves; operators continue to use --cancel with a JSON plan that includes log_dirs for those.
3. Throttles: If --preserve-throttles is not set, clear replication throttles only for brokers/topics implied by partitions that were actually cancelled (or document cluster-wide broker throttle behavior if implementation chooses otherwise—pick one and state it in the final KIP).
4. Partial failure: Per-partition errors from the controller (e.g. revert would require unclean leader election but topic disallows it) must be surfaced clearly; tool exits non-zero on any failed cancel.

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

...

• Wire protocol: None (reuses existing Admin APIs).
• CLI: Additive; no change to existing flags beyond new action.
• Security: Same ACL expectations as existing AlterPartitionReassignments / Describe paths; cluster-wide cancel is a high-privilege operation—call out in release notes / ops docs.

Why Not Just Document “List + Script”?

Listing and scripting is duplicated logic every organization reimplements, and it fails under stress. A first-class tool action matches how operators think (“cancel everything in flight”) and aligns with APIs the controller already supports.

Test Plan

• ReassignPartitionsCommandArgsTest: --cancel-all alone with --bootstrap-server parses; --reassignment-json-file rejected with cancel-all action; --cancel + --cancel-all rejected (single action); --preserve-throttles allowed; disallowed flags still rejected (e.g. --throttle, --reassignment-batch-size).
• ReassignPartitionsUnitTest (or equivalent): with MockAdminClient, start a partition reassignment, run cancelAllOngoingAssignments (or full command path), assert in-flight reassignment cleared and list state has no adding/removing for that partition.
• Error path: mock/controller response so one partition cancel fails → tool surfaces error and non-zero exit (if covered at unit level).

Rejected Alternatives

• Extend --cancel with a magic empty JSON / sentinel: Confusing and easy to misuse; a dedicated action is clearer.
• New RPC: Unnecessary; existing AlterPartitionReassignments already supports per-partition cancel.