[ 
https://issues.apache.org/jira/browse/KAFKA-10143?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jason Gustafson updated KAFKA-10143:
------------------------------------
    Description: 
Previously we could use --execute with the --throttle option in order to change 
the quota of an active reassignment. We seem to have lost this with KIP-455. 
The code has the following comment:
{code}
    val reassignPartitionsInProgress = zkClient.reassignPartitionsInProgress()
    if (reassignPartitionsInProgress) {
      // Note: older versions of this tool would modify the broker quotas here 
(but not
      // topic quotas, for some reason).  This behavior wasn't documented in 
the --execute
      // command line help.  Since it might interfere with other ongoing 
reassignments,
      // this behavior was dropped as part of the KIP-455 changes.
      throw new 
TerseReassignmentFailureException(cannotExecuteBecauseOfExistingMessage)
    }
{code}
Seems like it was a mistake to change this because it breaks compatibility. We 
probably have to revert. At the same time, we can make the intent clearer both 
in the code and in the command help output.


(Edit: in KIP-455, we changed the behavior so that changes require quota 
changes require the --additional flag. So this issue is mostly about ensuring 
we have the integration testing to cover that behavior.)

  was:
Previously we could use --execute with the --throttle option in order to change 
the quota of an active reassignment. We seem to have lost this with KIP-455. 
The code has the following comment:
{code}
    val reassignPartitionsInProgress = zkClient.reassignPartitionsInProgress()
    if (reassignPartitionsInProgress) {
      // Note: older versions of this tool would modify the broker quotas here 
(but not
      // topic quotas, for some reason).  This behavior wasn't documented in 
the --execute
      // command line help.  Since it might interfere with other ongoing 
reassignments,
      // this behavior was dropped as part of the KIP-455 changes.
      throw new 
TerseReassignmentFailureException(cannotExecuteBecauseOfExistingMessage)
    }
{code}
Seems like it was a mistake to change this because it breaks compatibility. We 
probably have to revert. At the same time, we can make the intent clearer both 
in the code and in the command help output.


> Add integration testing ensuring that the reassignment tool can change 
> replication quota with rebalance in progress
> -------------------------------------------------------------------------------------------------------------------
>
>                 Key: KAFKA-10143
>                 URL: https://issues.apache.org/jira/browse/KAFKA-10143
>             Project: Kafka
>          Issue Type: Bug
>          Components: core
>    Affects Versions: 2.6.0
>            Reporter: Jason Gustafson
>            Assignee: Jason Gustafson
>            Priority: Major
>             Fix For: 2.7.0, 2.6.1
>
>
> Previously we could use --execute with the --throttle option in order to 
> change the quota of an active reassignment. We seem to have lost this with 
> KIP-455. The code has the following comment:
> {code}
>     val reassignPartitionsInProgress = zkClient.reassignPartitionsInProgress()
>     if (reassignPartitionsInProgress) {
>       // Note: older versions of this tool would modify the broker quotas 
> here (but not
>       // topic quotas, for some reason).  This behavior wasn't documented in 
> the --execute
>       // command line help.  Since it might interfere with other ongoing 
> reassignments,
>       // this behavior was dropped as part of the KIP-455 changes.
>       throw new 
> TerseReassignmentFailureException(cannotExecuteBecauseOfExistingMessage)
>     }
> {code}
> Seems like it was a mistake to change this because it breaks compatibility. 
> We probably have to revert. At the same time, we can make the intent clearer 
> both in the code and in the command help output.
> (Edit: in KIP-455, we changed the behavior so that changes require quota 
> changes require the --additional flag. So this issue is mostly about ensuring 
> we have the integration testing to cover that behavior.)



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

Reply via email to