[BUG] Restarting the installation process can cause certificate problems if K8s was not fully configured

[romsok24]

Describe the bug
When reruning the epicli installation process one can fail with this error:

failed to connect to {https://127.0.0.1:2379  <nil> 0 <nil>}. Err :connection error: desc = "transport: authentication handshake failed: x509: certificate signed by unknown authority (possibly because of \"crypto/rsa: verification error\" while trying to verify candidate authority certificate \"etcd-ca\")"

How to reproduce
Steps to reproduce the behavior:

1. execute epicli init ... (with params)
2. if the installation from step on 1 will fail in between of kubernetes component creation - execute the step no 1 again

Expected behavior
On epicli preflight phase there should be a task to check for the existence of /etc/kubernetes/pki/ folder
and it should be cleaned if exists to ensure that all the certs from a brand new installation run will be signed with the most current CA cert.

Config files

Environment

• OS: Ubuntu 18.04.4 LTS

epicli version: 1.0.1

---

DoD checklist

• Changelog updated (if affected version was released)
• COMPONENTS.md updated / doesn't need to be updated
• Automated tests passed (QA pipelines)
  • apply
  • upgrade
• Case covered by automated test (if possible)
• Idempotency tested
• Documentation updated / doesn't need to be updated
• All conversations in PR resolved
• Backport tasks created / doesn't need to be backported

[atsikham]

@romsok24 is that a constant issue? On which step it failed during the first run? May be an investigation needed when it occurs.

We have a possibility to re-generate certificates. Someone could have custom validity period, I think pki folder should not be cleaned up each time for apply.

[romsok24]

Failing ansible task is: TASK [kubernetes_common : Update in-cluster configuration]

IMO - the failure is not related to the code but to the fact, that - as I wrote - part of the certs in /etc/kubernetes/pki/ are signed with the cA cert from the previous run and the other with the current one.

Cleaning this folder would be probably a good solution for this.

[przemyslavic]

Seems to be related to #1175.

[atsikham]

My proposal is to check this task after #2828 as it might be related.

[przemyslavic]

Tested multiple times apply command after cancelling the build at different stage. It went smoothly on re-apply.
The task on which the first build failed may be relevant here. I would close this task and re-open if it occurs again.