BugFix: Switchover (during a Node drain) fails randomly in synchronous mode #1984
Conversation
JBWatenbergScality
changed the title
JBWatenbergScality
force-pushed
the
synchronous-switchover-error
branch
2 times, most recently
from
e55aec0 to
0700909
Compare
JBWatenbergScality
requested review from
sdudoladov,
Jan-M,
CyberDem0n,
FxKu,
jopadi and
idanovinda
as code owners
| if err != nil { | ||
| return fmt.Errorf("could not get master candidate pod: %v", err) | ||
| } | ||
|
|
There was a problem hiding this comment.
getSwitchoverCandidate only picks a replica when state is running. I don't think we need another API call here.
There was a problem hiding this comment.
Indeed but then I will need to change getSwitchoverCandidate to make it return a Pod instead of a NamespacedName as below methods require a Pod. Another alternative would be to create a new getSwitchoverCandidatePod and refactor getSwitchoverCandidate to use that one if we want to keep the old signature. Which approach would you prefer ?
There was a problem hiding this comment.
ah I see. I think in this case, it's fine then. We would have to do the call anyway - whether it's here or in getSwitchoverCandidate. And the call does not happen each sync, so it's fine.
…migrating master pod to a replica Ref: zalando#1983
JBWatenbergScality
force-pushed
the
synchronous-switchover-error
branch
from
0700909 to
ffe6fe6
Compare
|
Hi @FxKu , I just rebased my branch as I saw the End-2-End tests were failing for reasons that doesn't seems to be related to my change. Not sure it will help through. Should I investigate those or assume that it is a flaky/ignore them ? |
|
👍 |
1 similar comment
|
👍 |
|
Thanks @JBWatenbergScality for this nice contribution! |
Change1: MigrateMasterPod now use getSwitchOverCandidate to select a new masterCandidate
Change2: Removed unused masterCandidate (replaced by getSwitchOverCandidate)
Fixes: #1983