Bug 1879034
| Summary: | Ironic boot_mode capabilities can end up empty when using bootMode: UEFI on baremetal host | ||
|---|---|---|---|
| Product: | OpenShift Container Platform | Reporter: | Asher Shoshan <ashoshan> |
| Component: | Installer | Assignee: | Doug Hellmann <dhellmann> |
| Installer sub component: | OpenShift on Bare Metal IPI | QA Contact: | Lubov <lshilin> |
| Status: | CLOSED ERRATA | Docs Contact: | |
| Severity: | high | ||
| Priority: | high | CC: | amalykhi, bnemec, dhellmann, rbartal, stbenjam, zbitter |
| Version: | 4.6 | Keywords: | Triaged, UpcomingSprint |
| Target Milestone: | --- | ||
| Target Release: | 4.6.0 | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | No Doc Update | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2020-10-27 16:41:13 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
Asher Shoshan
2020-09-15 09:18:06 UTC
This isn't related to the disabled provisioning network, for some reason baremetal-operator isn't setting capabilities correctly to tell the host we're doing a UEFI boot. BIOS-based virtualmedia provisioning won't work due to https://bugzilla.redhat.com/show_bug.cgi?id=1862608# Here's the properites field of the Ironic host: $ curl -g -X GET --user ironic-user:XXXXXXXX http://X.X.X.X:6385/v1/nodes/c4ccee33-20c3-471e-bf97-b20a8c730633 -H "Accept: application/json" -H "Content-Type: application/json" -H "X-Openstack-Ironic-API-Version: 1.67" | jq ".properties" shows: { "capabilities": "" } However, the BMH correctly shows bootMode: UEFI. @Doug: could there be some kind of race here and somehow capabilities ends up empty? It looks like the problem is that we only set the boot mode in ironic before we provision, and not before we start inspection. See https://github.com/metal3-io/baremetal-operator/pull/635 That's really odd because the e2e-metal-ipi-virtualmedia job was passing, using UEFI virtual media, did something change in Ironic or BMO? (In reply to Stephen Benjamin from comment #6) > That's really odd because the e2e-metal-ipi-virtualmedia job was passing, > using UEFI virtual media, did something change in Ironic or BMO? I had the impression that the boot mode setting for a VM didn't matter as much as it might for a physical host. Regardless, the patch mentioned in comment 5 is updating a gap we've always had in the original implementation. @Doug I run deployment with redgish-virtualmedia for provsioningNetework: Disabled and bootMode UEFI - it passed with no problem But I understand that's not enough to verify this BZ Could U, please, suggest what else should be verified? The original issue was with the timing of when we passed the boot mode to ironic. Before the fix, we only told ironic which boot mode to use when we were provisioning. That meant the host could fail to boot properly for inspection. To verify that ironic has the correct boot mode during inspection you could look at the node settings in ironic while the host is being inspected and verify that the value of /properties/capabilities includes a boot_mode value that matches the setting in the BareMetalHost resource. Verified on 4.6.0-0.nightly-2020-10-05-234751
While node is being inspected
(openstack-cli) [kni@provisionhost-0-0 ~]$ baremetal node show openshift-worker-0-2
| properties | {'capabilities': 'boot_mode:uefi'}
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 (OpenShift Container Platform 4.6 GA Images), 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-2020:4196 |