etcdserver: skip when detect a removed peer

[datbeohbbh]

resolve #17514

[k8s-ci-robot]

Hi @datbeohbbh. Thanks for your PR.

I'm waiting for a etcd-io member to verify that this patch is reasonable to test. If it is, they should reply with /ok-to-test on its own line. Until that is done, I will not automatically test new commits in this PR, but the usual testing commands by org members will still work. Regular contributors should join the org to skip this step.

Once the patch is verified, the new status will be reflected by the ok-to-test label.

I understand the commands that are listed here.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

[ahrtr]

/ok-to-test

[fuweid]

LGTM

[serathius]

Can we add a test? Any test.

[ahrtr]

Can we add a test? Any test.

It should be a very safe & very minor change change. We don't have to necessarily add a test for this PR.

Also we already have some membership related e2e and integration test cases. I think it's OK.

[serathius]

For me every bug that is worth backporting is also worth testing against.

[ahrtr]

I do not see how to reproduce this, so actually this PR fixed an non-exist issue. The fix just looks more natural (and of course safe and very minor) so we accepted it.

There is no point to waste time to get stuck on this. If you insist on adding a test, then provide detailed guide on how to do it. Or just close the backporting PRs or even revert the fix on main branch. I am not going to waste time on this, leave it to other maintainers & reviewer to take care of it since you have concern on it.

[serathius]

Thanks for confirming that this is not an issue. No need to backport it then.

I didn't expect that writing a unit test needs a detailed guideline. Please let me know what would make writing unit test harder in etcd so we need guideline for this?

My assumption is that backporting can have a unexpected consequences due to code differences, and it's a good practice to have a test that confirms the backport was done correctly. Looked into contributor documentation I think we are missing a backport guidelines that would make it more clear. Let me file an issue for that.

[ahrtr]

I didn't expect that writing a unit test needs a detailed guideline. Please let me know what would make writing unit test harder in etcd so we need guideline for this?

Unit test doesn't always fit for each kind of fix. Understanding the root cause is the prerequisite, otherwise it doesn't make sense to request to add a test.