Version: $ openshift-install version 4.6.17 Platform: baremetal Please specify: IPI What happened? In a lab setup we using hive to trigger a baremetal installation. The installation process creates the bootstrap VM but then does not go further than 80% and times out after 60 mins and the baremetal servers remain powered off. Using the same install-config with the openshift-installer directly works and produces a working cluster. #See the troubleshooting documentation (https://github.com/openshift/installer/blob/master/docs/user/troubleshooting.md) for ideas about what information to collect. #For example, # If the installer fails to create resources (https://github.com/openshift/installer/blob/master/docs/user/troubleshooting.md#installer-fails-to-create-resources), attach the relevant portions of your `.openshift_install.log.` # If the installer fails to bootstrap the cluster (https://github.com/openshift/installer/blob/master/docs/user/troubleshootingbootstrap.md), attach the bootstrap log bundle. # If the installer fails to complete installation after bootstrapping completes (https://github.com/openshift/installer/blob/master/docs/user/troubleshooting.md#installer-fails-to-initialize-the-cluster), attach the must-gather log bundle using `oc adm must-gather` # Always at least include the `.openshift_install.log` What did you expect to happen? Working cluster, servers powered on by the installation process Anything else we need to know?
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