Ignore non-voters in leadership transfer #398
Conversation
A leader should not initiate an election on a non-voter, causing it to temporarily become a leader for a short period of time.
|
|
raft_test.go
Outdated
|
|
||
| follower := c.Followers()[0] | ||
|
|
||
| demoteFuture := c.Leader().DemoteVoter(follower.localID, 0, 1*time.Nanosecond) |
There was a problem hiding this comment.
Could we make this a larger timeout or no timeout? Seems like 1 nanosecond could cause this to be flakey if go doesn't schedule the receiver right away.
There was a problem hiding this comment.
Thanks for the feedback - I changed this to zero.
|
@briankassouf Thank you for the review! I'm separately working on signing the CLA. I'm wondering if there's additional places where we'd want to protect against this occurring or if this is sufficient. For example, should a node to reject a TimeoutNow request if it is currently a non-voter? Should it be an invalid state transition to become a candidate if a node doesn't have a vote? |
|
@f3nry I think you are correct, a non-voter should not become a leader and should reject leadership transfers. There is an issue in Consul for your PR: hashicorp/consul#7031. And another one that is similar: hashicorp/consul#6979. The first one should be fixed by this PR. The last one is still open. |
|
@i0rek It seems like the second bug is mostly protected by the configuration index check on line 207.. Under what conditions would |
|
@briankassouf CLA is signed and PR is ready to go! |
|
@f3nry Great! Thanks! |
* 'master' of github.com:hashicorp/raft: more efficient append bytes (hashicorp#399) Ignore non-voters in leadership transfer (hashicorp#398)
A leader should not initiate an election on a non-voter, causing it to temporarily become a leader for a short period of time.