Why leader re-election should work after the default timeout 5-min when a worker node is failed?

[HyungJune]

Feature Request

Is your feature request related to a problem? Please describe.
A clear and concise description of what the problem is. Example: "I have an issue when (...)"

From /pkg/leader/leader.go, leader re-election works after the default timeout 5-min since the condition
Pod.status.phase == "Failed" && Pod.Status.Reason == "Evicted" when a worker node is failed.
I have an opinion that leader re-election can work almost immediately when the condition contains checking the status of the node where the leader pod is running.

Describe the solution you'd like
A clear and concise description of what you want to happen. Add any considered drawbacks.

the condition should change [Pod.status.phase == "Failed" && Pod.Status.Reason == "Evicted"] to [Pod.status.phase == "Failed" && Pod.Status.Reason == "Evicted" || Node.Status == "Not Ready"]

Making --pod-eviction-timeout to be short can be another approach. However, I sure that above approach can bring more reliability since we don't know appropriate time out.

I have a one more question..
What kinds of drawback exist when making --pod-eviction-timeout to be very very short?

[estroz]

@HyungJune given the placement of the condition you're referring to, you seem to be suggesting to look up the node the leader is on, and if it isn't ready then delete the pod on that node? That doesn't make sense to me, since the pod won't even exist if the node isn't ready. If that isn't what you meant, can you elaborate on your solution?

Also it's worth taking a look at #784, which discusses some of what you're talking about.

[HyungJune]

@estroz While I try to write my solution, the pkg (containing leader.go) in master branch is moved on "operator-lib" repository.
Do I create new issue (the same issue) and make pull request in "operator-lib" repository?

[HyungJune]

I move this issue to more appropriate repository (operator-framework/operator-lib#24).