-
Bug
-
Resolution: Done
-
Major
-
4.12.0
-
No
-
uShift Sprint 232, uShift Sprint 233
-
2
-
Rejected
-
False
-
Description of problem:
simply rebooting a R4E host puts the router service in a bad state and it takes the service too long to recover from it. In my case, it took over 5m, which fails the default Greenboot checks of restart count (a sign of greenboot validations working)
Version-Release number of selected component (if applicable):
Latest build from the main branch
How reproducible:
100%
Steps to Reproduce:
1. Create a R4E host 2. MAke sure MicroShift pods are up and running 3. Reboot
Actual results:
# oc get pods -A NAMESPACE NAME READY STATUS RESTARTS AGE openshift-dns dns-default-z4v2p 2/2 Running 4 23m openshift-dns node-resolver-sgsm4 1/1 Running 2 24m openshift-ingress router-default-85d64c4987-bbdnr 0/1 ContainerCreating 2 24m openshift-ovn-kubernetes ovnkube-master-86mcc 4/4 Running 9 24m openshift-ovn-kubernetes ovnkube-node-6gpbh 1/1 Running 2 24m openshift-service-ca service-ca-7bd9547b57-vhmkf 1/1 Running 2 24m openshift-storage topolvm-controller-78cbfc4867-qdfs4 4/4 Running 8 24m openshift-storage topolvm-node-9bnp5 4/4 Running 8 23m
Expected results:
Router pod starting immediatelly after boot
Additional info:
- clones
-
OCPBUGS-7779 The router pod is delayed over 5m after reboot
- Closed
- is blocked by
-
OCPBUGS-7779 The router pod is delayed over 5m after reboot
- Closed
- split from
-
OCPBUGS-6861 Some pods not coming up after rebooting
- Closed
-
OCPBUGS-10256 Some pods not coming up after rebooting
- Closed
- links to