Hi, We've identified some use cases that do not necessarily fit in with how participants are disabled today for full auto (auto rebalance) mode. For reference, here's what Helix currently supports:
- Disable participant: this participant will have its currently served replicas all go to the initial state and there will not be any transitions started from the initial state until the participant is enabled once more (depends on the rebalancing algorithm). The rebalancing algorithm may choose to serve these replicas on other participants while the participant is disabled. - Disable partition for participant: this participant will have its currently served replica go to the initial state and that replica will remain in that state until the participant is enabled once more (depending on the rebalancing algorithm). The rebalancing algorithm may choose to serve this replica on another participant while the participant is disabled. However, in some cases, when we disable a partition, we may not want the replicas to be reassigned to other participants because of a maintenance operation or other task. For instance, if we use OnlineOffline, and we disable a partition on a node that has that partition ONLINE, then there would simply not be any partition online until stop disabling the partition. One way to do this is to just disable the partition across the cluster. However, for state models that have multiple states, this doesn't really make sense. For instance, what should this do in MasterSlave? If we have 1 master and 2 slaves and disable the master, then should there just be 2 slaves, 1 master and 1 slave, or 1 master and 2 slaves with another node taking up the mastership? Does anyone have any thoughts on the utility of this new use case, what the semantics should be, and potential interfaces that could make sense here? Thanks, Kanak
