Bug 2104275
Summary: | Supermicro server FirmwareSchema CR does not contain allowable_values, attribute_type and read_only flag | ||
---|---|---|---|
Product: | OpenShift Container Platform | Reporter: | tali <tali> |
Component: | Bare Metal Hardware Provisioning | Assignee: | Dmitry Tantsur <dtantsur> |
Bare Metal Hardware Provisioning sub component: | ironic | QA Contact: | Jad Haj Yahya <jhajyahy> |
Status: | CLOSED ERRATA | Docs Contact: | |
Severity: | medium | ||
Priority: | high | CC: | janders, lshilin |
Version: | 4.11 | Keywords: | Triaged |
Target Milestone: | --- | ||
Target Release: | 4.12.0 | ||
Hardware: | x86_64 | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | If docs needed, set a value | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2023-01-17 19:51: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: |
Description
tali@redhat.com
2022-07-05 20:37:07 UTC
The must-gather is available: https://drive.google.com/file/d/1ssNvPHkQZX8_eLwUdfQNy4mNgCxAs4Gl/view?usp=sharing From what I can see, Ironic cannot find the BIOS attribute registry, thus the schema only contains the currently available fields. Could you please cURL your BMC to verify: curl -k https://<BMC IP>/redfish/v1/ If the JSON output contains a Registry link, could you follow it further? Here are the info you requested: curl -ksu ADMIN:ADMIN https://10.16.231.98/redfish/v1/ | jq . { "@odata.type": "#ServiceRoot.v1_5_2.ServiceRoot", "@odata.id": "/redfish/v1/", "Id": "RootService", "Name": "Root Service", "RedfishVersion": "1.8.0", "UUID": "00000000-0000-0000-0000-3CECEF59834C", "Systems": { "@odata.id": "/redfish/v1/Systems" }, "Chassis": { "@odata.id": "/redfish/v1/Chassis" }, "Managers": { "@odata.id": "/redfish/v1/Managers" }, "Tasks": { "@odata.id": "/redfish/v1/TaskService" }, "SessionService": { "@odata.id": "/redfish/v1/SessionService" }, "AccountService": { "@odata.id": "/redfish/v1/AccountService" }, "EventService": { "@odata.id": "/redfish/v1/EventService" }, "UpdateService": { "@odata.id": "/redfish/v1/UpdateService" }, "CertificateService": { "@odata.id": "/redfish/v1/CertificateService" }, "Registries": { "@odata.id": "/redfish/v1/Registries" }, "JsonSchemas": { "@odata.id": "/redfish/v1/JsonSchemas" }, "Links": { "Sessions": { "@odata.id": "/redfish/v1/SessionService/Sessions" } }, "Oem": { "Supermicro": {} } } curl -ksu ADMIN:ADMIN https://10.16.231.98/redfish/v1/Registries | jq { "@odata.type": "#MessageRegistryFileCollection.MessageRegistryFileCollection", "@odata.id": "/redfish/v1/Registries", "Name": "Registry File Collection", "Description": "Registry Repository", "Members": [ { "@odata.id": "/redfish/v1/Registries/BiosAttributeRegistry.v1_0_0" }, { "@odata.id": "/redfish/v1/Registries/Base.v1_4_0" }, { "@odata.id": "/redfish/v1/Registries/Event.v1_0_0" }, { "@odata.id": "/redfish/v1/Registries/SMC.v1_0_0" } ], "Members": 4 } curl -ksu ADMIN:ADMIN https://10.16.231.98/redfish/v1/Registries/BiosAttributeRegistry.v1_0_0 | jq . { "@odata.type": "#MessageRegistryFile.v1_1_3.MessageRegistryFile", "@odata.id": "/redfish/v1/Registries/BiosAttributeRegistry.v1_0_0", "Id": "BiosAttributeRegistry.v1_0_0", "@Redfish.Copyright": "Copyright 2014-2019 DMTF. All rights reserved.", "Name": "BIOS Attribute Registry File", "Description": "BIOS Attribute Registry File locations", "Languages": [ "en" ], "Registry": "BiosAttributeRegistry.1.0.0", "Location": [ { "Language": "en", "Uri": "/registries/BiosAttributeRegistry.1.0.0.json" } ], "Oem": {} } Thank you, appreciated? Could go one step further and fetch (and attach) /registries/BiosAttributeRegistry.1.0.0.json please? It looks like the uri is incorrect. SuperMicro support page says "it is a isolated issue on the 1.73.10 release". This serve is on Firmware Revision: 01.73.12. Let's see if we can upgrade it to a newer version. wget --no-check-certificate --user ADMIN --password ADMIN https://10.16.231.98/redfish/v1/Registries/BiosAttributeRegistry.1.0.0.json --2022-07-26 11:00:14-- https://10.16.231.98/redfish/v1/Registries/BiosAttributeRegistry.1.0.0.json Connecting to 10.16.231.98:443... connected. WARNING: cannot verify 10.16.231.98's certificate, issued by ‘CN=IPMI,OU=Software,O=Super Micro Computer,L=San Jose,ST=California,C=US’: Self-signed certificate encountered. WARNING: certificate common name ‘IPMI’ doesn't match requested host name ‘10.16.231.98’. HTTP request sent, awaiting response... 404 Not Found 2022-07-26 11:00:15 ERROR 404: Not Found. curl -ksu ADMIN:ADMIN https://10.16.231.98/redfish/v1/Registries/BiosAttributeRegistry.1.0.0.json <?xml version="1.0" encoding="iso-8859-1"?> <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> <html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en"> <head> <title>404 Not Found</title> </head> <body> <h1>404 Not Found</h1> </body> </html> Hmm, I checked your machine, and apparently this URL is correct: https://10.16.231.98/registries/BiosAttributeRegistry.1.0.0.json (note lower-case "registries" and no /redfish/v1 prefix). I will now check if we build the absolute URL correctly. I think see the issue. The Bios resource references registry BiosAttributeRegistry.v1_0_0, which exists, but its identity is BiosAttributeRegistry.1_0_0 (note the missing "v"). This confuses our code. This is probably something we can work around, although I wonder what their logic behind it was.. Right, the location uri is correct. Good catch!:-) Would you be able to verify this bug on 4.12? I'm afraid our QE may not have the same hardware. Yes, I will verify the fix on 4.12. Okay, we have another issue then: https://review.opendev.org/c/openstack/ironic/+/854760 Hi! The second fix will be available in the next accepted build, could you please test it again? I was informed that there were some issues with OLM in OCP 4.12. I will wait for the OLM team to merge the fix prior to installing 4.12 latest. Hi, have there been any progress with testing? Note that you don't necessarily need to do a complete installation, you only need to enroll a node and verify that the schema is correct. I was able to test the fix by patching the ironic image on a 4.11 hub cluster. This problem has been fixed. apiVersion: metal3.io/v1alpha1 kind: FirmwareSchema metadata: creationTimestamp: "2022-09-21T00:40:40Z" generation: 1 name: schema-f7afa37b namespace: cnfde11 ownerReferences: - apiVersion: metal3.io/v1alpha1 kind: HostFirmwareSettings name: cnfde11.ptp.lab.eng.bos.redhat.com uid: 7e44cf2f-a294-47cc-b5ee-0315fa2e9d4a resourceVersion: "36820971" uid: f6058489-2918-4cea-9b44-416945232a0a spec: schema: 2xRefresh: allowable_values: - Auto - Enable attribute_type: Enumeration read_only: false ACSControl: allowable_values: - Enable - Disable attribute_type: Enumeration read_only: false AES-NI: allowable_values: - Disable - Enable attribute_type: Enumeration read_only: false ARISupport: allowable_values: - Disabled - Enabled attribute_type: Enumeration read_only: false ATS: allowable_values: - Enable - Disable attribute_type: Enumeration read_only: false Above4GDecoding: allowable_values: - Disabled - Enabled attribute_type: Enumeration ... 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.12.0 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-2022:7399 |