Bug 1888375 - Setting Supermicro node to PXE boot via Redfish doesn't take affect
Summary: Setting Supermicro node to PXE boot via Redfish doesn't take affect
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat OpenStack
Classification: Red Hat
Component: openstack-ironic
Version: 16.0 (Train)
Hardware: Unspecified
OS: Unspecified
medium
high
Target Milestone: z7
: 16.1 (Train on RHEL 8.2)
Assignee: Steve Baker
QA Contact:
URL:
Whiteboard:
Depends On: 1888072 1892302 1945701
Blocks:
TreeView+ depends on / blocked
 
Reported: 2020-10-14 17:18 UTC by Julia Kreger
Modified: 2021-12-09 20:17 UTC (History)
10 users (show)

Fixed In Version: openstack-ironic-13.0.7-1.20210603224532.3d77e61.el8ost
Doc Type: If docs needed, set a value
Doc Text:
Clone Of: 1888072
Environment:
Last Closed: 2021-12-09 20:17:24 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
OpenStack gerrit 758856 0 None MERGED Sync boot mode when changing the boot device via Redfish 2021-02-11 16:57:12 UTC
Red Hat Issue Tracker OSP-1440 0 None None None 2021-11-18 11:28:55 UTC
Red Hat Product Errata RHBA-2021:3762 0 None None None 2021-12-09 20:17:49 UTC

Description Julia Kreger 2020-10-14 17:18:37 UTC
+++ This bug was initially created as a clone of Bug #1888072 +++

Description of problem:

Starting with a Supermicro node set to PXE boot (it was manually set via IPMI) we see Ironic able to successfully do a deployment and set the node to boot from disk using Redfish. However deploying a second time will fail because the node will keep bootinh to disk, it appears the Redfish command that Ironic send to change to PXE boot is not taking affect, perhaps because of the BootSourceOverrideEnabled setting.

The first time the node is set to boot from disk after writing the image:
2020-10-13 21:28:31.152 1 DEBUG sushy.connector [req-4841e280-8461-4351-a09a-5c8cfbe2c17a - - - - -] HTTP request: PATCH https://mgmt-f07-h13-000-1029p.rdu2.scalelab.redhat.com/redfish/v1/Systems/1; headers: {'OData-Version': '4.0'}; body: {'Boot': {'BootSourceOverrideTarget': 'Hdd', 'BootSourceOverrideEnabled': 'Continuous'}}; blocking: False; timeout: 60; session arguments: {}; _op /usr/lib/python3.6/site-packages/sushy/connector.py:102

And it takes affect and does boot from disk:
'IndicatorLED': 'Off', 'PowerState': 'On', 'Boot': {'BootSourceOverrideEnabled': 'Continuous', 'BootSourceOverrideMode': 'Legacy', 'BootSourceOverrideTarget': 'Hdd',

We see the command to not boot persistent:
2020-10-13 21:28:41.398 1 DEBUG sushy.connector [req-33f87403-3090-4afb-8c04-f8042aa61f81 - - - - -] HTTP request: PATCH https://mgmt-f06-h15-000-1029p.rdu2.scalelab.redhat.com/redfish/v1/Systems/1; headers: {'OData-Version': '4.0'}; body: {'Boot': {'BootSourceOverrideTarget': 'Hdd'}};

which results in BootSourceOverrideEnabled 'Once'
'PowerState': 'On', 'Boot': {'BootSourceOverrideEnabled': 'Once', 'BootSourceOverrideMode': 'Legacy', 'BootSourceOverrideTarget': 'Hdd',

And eventually:
'Boot': {'BootSourceOverrideEnabled': 'Disabled', 'BootSourceOverrideMode': 'Legacy', 'BootSourceOverrideTarget': 'Non

=========

On the second deployment we see:
'Boot': {'BootSourceOverrideEnabled': 'Disabled', 'BootSourceOverrideMode': 'Legacy', 'BootSourceOverrideTarget': 'None',

Then the command set back to PXE boot for introspection:
2020-10-13 19:56:45.095 1 DEBUG sushy.connector [req-6194fdaf-04ad-4c58-a51d-678af46bb6d3 - - - - -] HTTP request: PATCH https://mgmt-f06-h14-000-1029p.rdu2.scalelab.redhat.com/redfish/v1/Systems/1; headers: {'OData-Version': '4.0'}; body: {'Boot': {'BootSourceOverrideTarget': 'Pxe', 'BootSourceOverrideEnabled': 'Once'}}; blocking: False; timeout: 60; session arguments: {}; _op /usr/lib/python3.6/site-packages/sushy/connector.py:102^[[00m
2020-10-13 19:56:45.113 1 DEBUG sushy.connector [req-8b759858-1468-4051-98b8-a6bd4985df89 - - - - -] HTTP response for GET https://mgmt-f07-h13-000-1029p.rdu2.scalelab.redhat.com/redfish/v1/Systems/1: status code: 200 _op /usr/lib/python3.6/site-packages/sushy/connector.py:156

It is sent a 2nd time shortly after:
2020-10-13 19:56:45.113 1 DEBUG sushy.connector [req-8b759858-1468-4051-98b8-a6bd4985df89 - - - - -] HTTP request: PATCH https://mgmt-f07-h13-000-1029p.rdu2.scalelab.redhat.com/redfish/v1/Systems/1; headers: {'OData-Version': '4.0'}; body: {'Boot': {'BootSourceOverrideTarget': 'Pxe', 'BootSourceOverrideEnabled': 'Once'}}; blocking: False; timeout: 60; session arguments: {}; _op /usr/lib/python3.6/site-packages/sushy/connector.py:102

We can see in a subsequent get that the BootSourceOverrideEnabled and BootSourceOverrideTarget have changed:
IndicatorLED': 'Off', 'PowerState': 'Off', 'Boot': {'BootSourceOverrideEnabled': 'Once', 'BootSourceOverrideMode': 'Legacy', 'BootSourceOverrideTarget': 'Pxe', 'BootSourceOverrideTarget': ['None', 'Pxe', 'Floppy', 'Cd', 'Usb', 'Hdd', 'BiosSetup']},

ironic reboots the node (with this warning which is a separate issue):
020-10-13 19:56:59.846 1 WARNING sushy.resources.system.system [req-6194fdaf-04ad-4c58-a51d-678af46bb6d3 - - - - -] Could not figure out the allowed values for the reset system action for System 1^[[00m
2020-10-13 19:56:59.846 1 DEBUG sushy.connector [req-6194fdaf-04ad-4c58-a51d-678af46bb6d3 - - - - -] HTTP request: POST https://mgmt-f06-h14-000-1029p.rdu2.scalelab.redhat.com/redfish/v1/Systems/1/Actions/ComputerSystem.Reset; headers: {'OData-Version': '4.0'}; body: {'ResetType': 'On'}; blocking: False; timeout: 60; session arguments: {}; _op /usr/lib/python3.6/site-packages/sushy/connector.py:102

** However the node boots to disk, not PXE. **

Eventually the node will return:
Boot': {'BootSourceOverrideEnabled': 'Disabled', 'BootSourceOverrideMode': 'Legacy', 'BootSourceOverrideTarget': 'None',


This is with:
Hardware - Supermicro 1029P
Firmware Revision: 01.71.17
BIOS Version: 3.0a
Redfish Version: 1.0.1

--- Additional comment from Bob Fournier on 2020-10-14 12:04:57 UTC ---

Comment 4 Steve Baker 2021-04-06 22:03:22 UTC
setting back to ON_DEV, this change is being reverted and will be re-proposed with other changes

Comment 7 Steve Baker 2021-04-27 21:53:30 UTC
The fix is now proposed downstream in the series for bug #1945701

Comment 26 errata-xmlrpc 2021-12-09 20:17:24 UTC
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 (Red Hat OpenStack Platform 16.1.7 (Train) bug fix and enhancement 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-2021:3762


Note You need to log in before you can comment on or make changes to this bug.