Description of problem:
The etcd restore procedure (https://docs.openshift.com/container-platform/4.12/backup_and_restore/control_plane_backup_and_restore/disaster_recovery/scenario-2-restoring-cluster-state.html) does not indicate that we have to use the installation admin kubeconfig or any other client certificate based kubeconfig (like the ones from https://access.redhat.com/solutions/4845381). It even asks us to do "oc login" with oauth-based users at some steps (like 17). Problem: During the procedure, some cluster components may be KO, specially the SDN (and that's more expected if the SDN is OVN Kubernetes, at least until OVN database rebuild is completed and OVN control plane runs single-node). In such scenario, oauth may not work and it may be impossible to use oauth-based users, so client-certificate kubeconfigs (like the ones from installation) have to be used. It is important to note that this may be difficult to reproduce from a QA point of view, because it greatly depends on the environment. This has however happened in an end-user environment and this was pretty the rationale, hence why we are requesting this change.
Version-Release number of selected component (if applicable):
4.10-4.13
How reproducible:
Sometimes
Steps to Reproduce:
1. Follow the guide without using client certificate based kubeconfig 2. 3.
Actual results:
Procedure impossible due to expected oauth malfunction
Expected results:
Procedure possible because we recommended using client certificate kubeconfig, so it does not matter if oauth is KO
Additional info: