Bug 1932799
Summary: | During a hive driven baremetal installation the process does not go beyond 80% in the bootstrap VM | ||
---|---|---|---|
Product: | OpenShift Container Platform | Reporter: | Ulrich Schlueter <uschlute> |
Component: | Installer | Assignee: | Beth White <beth.white> |
Installer sub component: | OpenShift on Bare Metal IPI | QA Contact: | Raviv Bar-Tal <rbartal> |
Status: | CLOSED ERRATA | Docs Contact: | |
Severity: | urgent | ||
Priority: | high | CC: | augol, pablo.iranzo, rbartal, stbenjam |
Version: | 4.6.z | Keywords: | OtherQA, Reopened, Triaged |
Target Milestone: | --- | ||
Target Release: | 4.8.0 | ||
Hardware: | x86_64 | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | Bug Fix | |
Doc Text: |
Baremetal IPI previously required that the installer was able to communicate with the provisioning network. This changes that communication to happen over the API VIP, enabling cases where the provisioning network is not routable and the installer is being run from a remote location, such as from Hive or ACM. Users may need to adjust their firewall rules to allow communication with TCP ports 6385 and 5050 on the API VIP.
|
Story Points: | --- |
Clone Of: | Environment: | ||
Last Closed: | 2021-07-27 22:48:26 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: | 1831748, 1935163 |
Description
Ulrich Schlueter
2021-02-25 09:53:53 UTC
Reading through the logs, the ironic API failed to come up. That's usually indicative OS images failed to download. If you ssh to the bootstrap, can you run /usr/local/bin/installer-gather.sh on the bootstrap and attach the tarball to the BZ? That'll include all the logs I should need from the bootstrap. Back when we tested Hive and baremetal IPI, we were using a setup that included routable provisioning networks and that was a constraint at the time. The installer needed to communicate with the provisioning (ironic) API's hosted on the bootstrap host using the bootstrap provisioning IP. However, since 4.7 it should be possible to use the API VIP's instead. In fact, when using virtual media with the provisioning network disabled, we already use the API VIP, so it probably makes sense to make the installer always do this regardless of whether there's a network or not. I have to have some other people look at my proposal for this, I hope I'm not overlooking something. For earlier than 4.7, I don't have any immediate ideas how to workaround this, without making the provisioning network routable. Hey Ulrich, Can you please re-test in our lab environment, and update this BZ? Thanks Raviv For now you'll need to use a recent 4.8 nightly. I am not entirely sure yet we can backport this to 4.7.z, it might be surprising to customers if we change which IP the installer is talking to in a z-stream for provisioning *** This bug has been marked as a duplicate of bug 1936443 *** Amit why did you mark this as a duplicate of 1936443? They look like entirely different issues. BZ was verified by the ACM team on baremetal. 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 (Moderate: OpenShift Container Platform 4.8.2 bug fix and security update), 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/RHSA-2021:2438 |