Description of problem: Issue is that the Sushy library has strict controls around values of fields and interpreted any field with a string value of 'None' to be invalid, however in the redfish specification, the string 'None' is actually a valid value. This strict validation code was introduced during the OpenStack Train development cycle. How reproducible: Every time when boot mode must be changed with ironic. Steps to Reproduce: 1. Using ironic, with a redfish supporting machine (idrac8, 2.70.70.70 or idrac9, or HPE ilo), when starting from "Legacy" boot mode. 2. Attempt to deploy a machine using the 'redfish' driver, with the boot mode set to 'uefi' Actual results: Error is returned to the user. "last_error": "Failed to prepare to deploy: Redfish exception occurred. Error: Setting boot mode to uefi failed for node 9c1a786e-dc1c-41a0-90ff-03323efdefb2. Error: The parameter \"target\" value \"None\" is invalid. Valid values are: {'sd card', 'uefi http', 'bios setup', 'hdd', 'none', 'floppy', 'pxe', 'uefi target', 'utilities', 'cd'}", Expected results: Machine deploys. Additional info: In reviewing log data, we can see the BMC reply with a list of valid targets, however the list of targets that is returned excludes 'BootSourceOverrideTarget': 'None', 'BootSourceOverrideTarget': ['None', 'Pxe', 'Cd', 'Floppy', 'Hdd', 'BiosSetup', 'Utilities', 'UefiTarget', 'SDCard', 'UefiHttp'] Note: there is some field text mapping that occurs here, but regardless we can see 'None' is getting stripped. This was patched upstream, however a series of backports are required to fix this issue. https://storyboard.openstack.org/#!/story/2006641 https://storyboard.openstack.org/#!/story/2007216 Train backports: https://review.opendev.org/#/c/707508/1 https://review.opendev.org/#/c/707511/1 https://review.opendev.org/#/c/707512/1
Verified that all patches are available in 16.0.2, compose for 4/6/20202, rpm - python3-sushy-2.0.2-0.20200225134404.3f08acc.el8ost.noarch. Functionality has been verified in Telco 5G Redfish testing.
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, 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:2155
The needinfo request[s] on this closed bug have been removed as they have been unresolved for 1000 days