I'm starting to think about KIP-179 again. In order to have more manageably-scoped KIPs and PRs I think it might be worth factoring-out the throttling part into a separate KIP. Wdyt?
Keeping the throttling discussion in this thread for the moment... The throttling behaviour is currently spread across the `(leader|follower). replication.throttled.replicas` topic config and the `(leader|follower).replication.throttled.rate` dynamic broker config. It's not really clear to me exactly what "removing the throttle" is supposed to mean. I mean we could reset the rate to Long.MAV_VALUE or we could change the list of replicas to an empty list. The ReassignPartitionsCommand does both, but there is some small utility in leaving the rate, but clearing the list, if you've discovered the "right" rate for your cluster/workload and to want it to be sticky for next time. Does any one do this in practice? With regards to throttling, it would be >> worth thinking about a way where the throttling configs can be >> automatically removed without the user having to re-run the tool. >> > > Isn't that just a matter of updating the topic configs for > (leader|follower).replication.throttled.replicas at the same time we > remove the reassignment znode? That leaves open the question about whether > to reset the rates at the same time. > Thinking some more about my "update the configs at the same time we remove the reassignment znode" suggestion. The reassignment znode is persistent, so the reassignment will survive a zookeeper restart. If there was a flag for the auto-removal of the throttle it would likewise need to be persistent. Otherwise a ZK restart would remember the reassignment, but forget about the preference for auto removal of throttles. So, we would use a persistent znode (a child of the reassignment path, perhaps) to store a flag for throttle removal. Thoughts? Cheers, Tom
