Bug 1795277
| Summary: | oc debug node/<node-name> tries to pull non s390x rhel7/support-tools image | ||
|---|---|---|---|
| Product: | OpenShift Container Platform | Reporter: | Alexander Klein <alklein> |
| Component: | Multi-Arch | Assignee: | David Benoit <dbenoit> |
| Status: | CLOSED CURRENTRELEASE | QA Contact: | Barry Donahue <bdonahue> |
| Severity: | urgent | Docs Contact: | |
| Priority: | high | ||
| Version: | 4.2.z | CC: | crawford, dbenoit, dorzel, epasch, Holger.Wolf, jpoulin, wvoesch |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | s390x | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | If docs needed, set a value | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2020-02-13 15:36:11 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: | |||
| Bug Depends On: | |||
| Bug Blocks: | 1777031 | ||
|
Description
Alexander Klein
2020-01-27 15:51:21 UTC
We will need to mention in the documentation that s390x users need to specify the RHEL 8 support-tools image. oc debug --image=registry.redhat.io/rhel8/support-tools this works for me Also reported in https://bugzilla.redhat.com/show_bug.cgi?id=1777030. Let's use this one though, since it has more information. *** Bug 1777030 has been marked as a duplicate of this bug. *** *** Bug 1777031 has been marked as a duplicate of this bug. *** *** Bug 1778807 has been marked as a duplicate of this bug. *** https://access.redhat.com/containers/#/registry.access.redhat.com/rhel7/support-tools now reports that it supports AMD64, ppc64le, and s390x. I tested oc debug node/<node-name> on four different clusters. It worked on three out of the four clusters. I noticed that the clusters on which the command worked have version 4.2.16 and the one on which it didn't worked has version 4.2.12. I think different versions should not influence whether the command works or not, as the registry is external. Do you have any idea why the command works three out of four times? (In reply to wvoesch from comment #10) > I tested oc debug node/<node-name> on four different clusters. It worked on > three out of the four clusters. > Not acceptable - please reopen the bug! I tested again and now in general the command works on all four clusters. However this time I got once a different error: # oc debug node/<node-name> Starting pod/<node-name-debug> ... To use host binaries, run `chroot /host` Removing debug pod ... error: unable to create the debug pod "<node-name-debug> " I tried to start the debug container on another node and it worked so I retried it on the node where it didn't work first time. The second time it works: # oc debug node/<node-name> Starting pod/<node-name-debug> ... To use host binaries, run `chroot /host` Pod IP: <pod-ip> If you don't see a command prompt, try pressing enter. sh-4.2# So it still doesn't work reliably. Can you reopen this bug? For the future: Can you automate this testcase - try all clusters that you have. For each cluster try 100 times.... We probably should keep this in the regression test bucket for a while.... So, the underlying Multi-Arch related issue here was that the container being pulled did not support non-x86_64 architectures. This has been fixed and verified. If you're now hitting an intermittent issue with oc debug node, that is a new issue altogether, since it is not related to the change of the underlying issue that this bug was tracking. If you can reproduce the intermittent issue on your clusters, I suggest you file a new bug with instructions on how to reproduce, so that we can narrow in on the new problem. As discussed in the bugzapper call - we close this issue as it was resolved and will open a new one as soon we have re-tested if the reliability needs to be improved. |