Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

recover-control-plane.yml does not work when the broken node is offline #10649

Closed
yuha0 opened this issue Nov 25, 2023 · 1 comment · Fixed by #10660
Closed

recover-control-plane.yml does not work when the broken node is offline #10649

yuha0 opened this issue Nov 25, 2023 · 1 comment · Fixed by #10660
Assignees
Labels
kind/bug Categorizes issue or PR as related to a bug.

Comments

@yuha0
Copy link
Contributor

yuha0 commented Nov 25, 2023

playbook exits with node unreachable error

Currently, recover-control-plane.yml only works if the broken control plane node is reachable. When the node is offline, task Remove etcd data dir will fail and break the playbook run. ignore_errors: true bypasses only task failure but not cases like node unreachable, and one would need to add ignore_unreachable: true.

Clarification in runbook

Also, it's probably very obvious to etcd experts, but the runbook, Recovering the control plane, does not mention that the newly added replacement node needs to set the same etcd_memeber_name variable as the broken one, otherwise, when joining the cluster, the new etcd node will get an "ignored streaming request; ID mismatch" error.

In the runbook, the last section has:

* If your new control plane nodes have new ip addresses you may have to change settings in various places.

It's very vague and I find it a bit confusing. In fact, I am not sure if this is still needed at all. The main control plane role already has a task to update etcd node IPs in api-server configs, and all the certificates were updated by the existing tasks automatically. After finishing the execution of recover-control-plane.yml, I didn't have to do anything. Granted the replacement node I used had the same IP address as the one that's broken, and I didn't have the opportunity to test the scenario when the replacement node has a new IP.

Environment:

  • Version of Ansible (ansible --version): 2.12.5

  • Version of Python (python --version): 3.9.18

Kubespray version (commit) (git rev-parse --short HEAD): 2.22.0

@yuha0 yuha0 added the kind/bug Categorizes issue or PR as related to a bug. label Nov 25, 2023
@yuha0
Copy link
Contributor Author

yuha0 commented Nov 28, 2023

/assign

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
kind/bug Categorizes issue or PR as related to a bug.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant