Bug 1745811
| Summary: | OCP 4.2 - Azure image-registry pods in CrashLoopBackoff after cluster install | ||
|---|---|---|---|
| Product: | OpenShift Container Platform | Reporter: | Walid A. <wabouham> |
| Component: | Image Registry | Assignee: | Ricardo Maraschini <rmarasch> |
| Status: | CLOSED ERRATA | QA Contact: | XiuJuan Wang <xiuwang> |
| Severity: | high | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | 4.2.0 | CC: | adam.kaplan, aos-bugs, mifiedle, nstielau, rmarasch, xiuwang |
| Target Milestone: | --- | ||
| Target Release: | 4.2.0 | ||
| Hardware: | x86_64 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | If docs needed, set a value | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2019-10-16 06:37:54 UTC | Type: | Bug |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
|
Description
Walid A.
2019-08-27 02:04:47 UTC
I don't reproduce this issue with 4.2.0-0.nightly-2019-08-26-202352 payload $ oc get pods -n openshift-image-registry NAME READY STATUS RESTARTS AGE cluster-image-registry-operator-dbf75d975-mfb5w 2/2 Running 0 66m image-registry-58654c58cd-gsctf 1/1 Running 0 63m node-ca-9522m 1/1 Running 0 63m node-ca-gsh84 1/1 Running 0 63m node-ca-j2nnp 1/1 Running 0 63m node-ca-tz627 1/1 Running 0 63m node-ca-zd5r2 1/1 Running 0 63m [xiuwang@dhcp-141-173 tmp]$ oc get clusterversion NAME VERSION AVAILABLE PROGRESSING SINCE STATUS version 4.2.0-0.nightly-2019-08-26-202352 True False 60m Cluster version is 4.2.0-0.nightly-2019-08-26-202352 @Walid Could you paste which version of installer you used? @XiuJuan I used installer from automated installer Jenkins job: ./openshift-install v4.2.0-201908251340-dirty built from commit c2e6b0afd7f33ae0125d1ac96f3948919748ffc5 release image registry.svc.ci.openshift.org/ocp/release@sha256:0143dc81a5d87bba07c20b7800742b58e24a201f1a1706b0a4f5374cab22e415 Hmm, My jenkins jobs both succeed installation with 4.2.0-0.nightly-2019-08-25-233755 and 4.2.0-0.nightly-2019-08-26-202352 in azure yesterday. Right now we're about 50% pass rate on Azure CI, which is running every 4 hours, and on-demand from PRs. You may be hitting some of the same flakes CI is. https://testgrid.k8s.io/redhat-openshift-release-informing#redhat-canary-openshift-ocp-installer-e2e-azure-4.2 When set the REGISTRY_STORAGE_AZURE_CONTAINER=qe-xiuwang--azure-909-74z7s-image-registry-qyctpisglrltvbixdqrw manually in 4.2.0-0.nightly-2019-09-08-180038 version，the image-registry pod will be CrashLoopBackOff. It's better to restrict a sequence of dashes saved in config.imageregistry.operator.openshift.io XiuJuan - the fix ensures that we don't have an invalid container name for IPI installs, or UPI installations where the container name is not provided. If a customer provides a bad container name for UPI installs, failing with a CrashLoopBackoff - though not ideal - is not a release blocker. Please file a separate bug for this. Please verify that if a container name is not provided (UPI or IPI installs), that we generate a valid container name on Azure. Adam, Thanks, I will open a new low bug to track issue in comment #9 . Installed several azure clusters with IPI installation, also checked azure ci, didn't find the image-registry pods in CrashLoopBackoff error. All generated container name has no a sequence of dashes, such as hongli-azupg-x2v5q-image-registry-uckvbxabnnvpkfmdopbgjxuyuici Checked with 4.2.0-0.nightly-2019-09-08-180038 payload. Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHBA-2019:2922 |