|
|
Post by jyundt on Apr 26, 2023 18:33:58 GMT
This is related to ansible-collections/community.general#6433 and ansible-collections/community.general#6434, what is the expected behavior with the Service Validator if a @redfish.Settings property for Bios is not present? Should this result in a fail? For context, we have a server vendor that does not include this which results in breakage with the Ansible Redfish modules. I ran the Service Validator against a sample server and expected to get failures, but everything passed. |
|
|
|
Post by mraineri on Apr 26, 2023 18:43:26 GMT
Technically @redfish.Settings isn't mandatory per the schema definition, so I would not expect the service validator to pick up on this.
In terms of practical usage, I would expect it on a Bios resource. However, it's theoretically possible that an implementation could have a special feature where it really does push BIOS attributes in a live manner, but I don't think this is terribly realistic.
Maybe this checking might be better suited for a use case checker? Or perhaps a Redfish profile to enforce the expectation that @redfish.Settings is necessary for acceptance?
|
|
|
|
Post by jyundt on Apr 26, 2023 20:24:50 GMT
Ah got it. An answer of "Use an Interop Profile" works for me, thank you!
|
|
|
|
Post by mraineri on Apr 26, 2023 20:33:32 GMT
While an interop profile can help here, the thing that worries me is we have this statement in the spec:
> "For resources that support a future intended state, the response shall contain a property with the @redfish.Settings payload annotation."
It's a pretty hard requirement, and this particular implementation violates that "shall" statement. I would like to spend some time to think of another path for testing this without requiring the usage of a profile.
|
|
|
|
Post by mraineri on Apr 26, 2023 20:54:42 GMT
One thought coming to mind: add this in the protocol validator that does other "shall" testing. Since "Bios" is pretty reasonable for testing, we could have logic something like this:
- Scan each member of /redfish/v1/Systems for "Bios" resources. If /redfish/v1/Systems is not implemented or no Bios resources are found, end the test as "not tested".
- For each "Bios" resource found, check if @redfish.Settings is present. If present, end the test as "passed".
- For each "Bios" resource that lacks "@redfish.Settings", attempt a GET request on well-known settings URIs (append /SD and /Settings). If any of these URIs return 200 OK, end the test as "failed".
As other common places for settings resources are found, we can expand the list of resources to probe in this manner.
|
|
|
|
Post by jyundt on Apr 26, 2023 21:17:52 GMT
Works for me, I like it!
|
|
|
|
Post by mraineri on May 1, 2023 21:04:03 GMT
|
|
|
|
Post by jyundt on May 1, 2023 21:17:21 GMT
As a quick sanity check, should this result in a FAIL or a "NOT_TESTED"? I used your PR branch against a server that doesn't have a @redfish.Settings property and got "NOT_TESTED":  Sample curl snippet: (venv) jyundt@jyundt-1:~/git/Redfish-Protocol-Validator$ curl -skL -u ADMIN:hunter2 https://192.168.100.100/redfish/v1/Systems/Self/Bios | jq '.' | head -n 20
{
"@odata.context": "/redfish/v1/$metadata#Bios.Bios",
"@odata.etag": "W/\"1682644317\"",
"@odata.id": "/redfish/v1/Systems/Self/Bios",
"@odata.type": "#Bios.v1_1_0.Bios",
"Actions": {
"#Bios.ChangePassword": {
"@Redfish.ActionInfo": "/redfish/v1/Systems/Self/Bios/ChangePasswordActionInfo",
"target": "/redfish/v1/Systems/Self/Bios/Actions/Bios.ChangePassword"
},
"#Bios.ResetBios": {
"@Redfish.ActionInfo": "/redfish/v1/Systems/Self/Bios/ResetBiosActionInfo",
"target": "/redfish/v1/Systems/Self/Bios/Actions/Bios.ResetBios"
}
},
"AttributeRegistry": "BiosAttributeRegistry",
"Attributes": {
"EagleStream0001": "ALL LPs",
"EagleStream0002": "Enable",
"EagleStream0003": "Disable",
(venv) jyundt@jyundt-1:~/git/Redfish-Protocol-Validator$ |
|
|
|
Post by mraineri on May 2, 2023 12:53:33 GMT
Quite possible there's a bug in the probing logic; I'll take a closer look. Can you check if you can use curl with the URLs "https://192.168.100.100/redfish/v1/Systems/Self/Bios/SD" or "https://192.168.100.100/redfish/v1/Systems/Self/Bios/Settings"? |
|
|
|
Post by jyundt on May 2, 2023 15:50:31 GMT
Nothing at either of those URIs:
jyundt@jyundt-1:~$ curl -skL -u ADMIN:hunter2 https://192.168.100.100/redfish/v1/Systems/Self/Bios | jq '.' | head -n 20
{
"@odata.context": "/redfish/v1/$metadata#Bios.Bios",
"@odata.etag": "W/\"1682891286\"",
"@odata.id": "/redfish/v1/Systems/Self/Bios",
"@odata.type": "#Bios.v1_1_0.Bios",
"Actions": {
"#Bios.ChangePassword": {
"@Redfish.ActionInfo": "/redfish/v1/Systems/Self/Bios/ChangePasswordActionInfo",
"target": "/redfish/v1/Systems/Self/Bios/Actions/Bios.ChangePassword"
},
"#Bios.ResetBios": {
"@Redfish.ActionInfo": "/redfish/v1/Systems/Self/Bios/ResetBiosActionInfo",
"target": "/redfish/v1/Systems/Self/Bios/Actions/Bios.ResetBios"
}
},
"AttributeRegistry": "BiosAttributeRegistry",
"Attributes": {
"EagleStream0001": "ALL LPs",
"EagleStream0002": "Enable",
"EagleStream0003": "Disable",
jyundt@jyundt-1:~$ curl -skL u ADMIN:hunter2 https://192.168.100.100/redfish/v1/Systems/Self/Bios/SD | jq '.'
{
"error": {
"@Message.ExtendedInfo": [
{
"@odata.type": "#Message.v1_0_8.Message",
"Message": "The resource at the URI '/redfish/v1/Systems/Self/Bios/SD' was not found.",
"MessageArgs": [
"/redfish/v1/Systems/Self/Bios/SD"
],
"MessageId": "Base.1.12.ResourceMissingAtURI",
"Resolution": "Place a valid resource at the URI or correct the URI and resubmit the request.",
"Severity": "Critical"
}
],
"code": "Base.1.12.ResourceMissingAtURI",
"message": "The resource at the URI '/redfish/v1/Systems/Self/Bios/SD' was not found."
}
}
jyundt@jyundt-1:~$ curl -skL u ADMIN:hunter2 https://192.168.100.100/redfish/v1/Systems/Self/Bios/Settings | jq '.'
{
"error": {
"@Message.ExtendedInfo": [
{
"@odata.type": "#Message.v1_0_8.Message",
"Message": "The resource at the URI '/redfish/v1/Systems/Self/Bios/Settings' was not found.",
"MessageArgs": [
"/redfish/v1/Systems/Self/Bios/Settings"
],
"MessageId": "Base.1.12.ResourceMissingAtURI",
"Resolution": "Place a valid resource at the URI or correct the URI and resubmit the request.",
"Severity": "Critical"
}
],
"code": "Base.1.12.ResourceMissingAtURI",
"message": "The resource at the URI '/redfish/v1/Systems/Self/Bios/Settings' was not found."
}
}
jyundt@jyundt-1:~$
|
|
|
|
Post by mraineri on May 2, 2023 17:07:55 GMT
Ah, that's good at least, which means the "NOT_TESTED" is correct here since neither of the URIs it checked were accessible... Is there a different URI for the settings resource, or is it simply not implemented?
|
|
|
|
Post by mraineri on May 2, 2023 20:41:54 GMT
Remembering the Ansible discussion now... Are you able to perform POST on "/redfish/v1/Systems/Self/Bios/SD", but not GET?
|
|
|
|
Post by jyundt on May 3, 2023 16:03:51 GMT
I was chatting with Scott and I think the TL;DR on this broken BMC behavior for /redfish/v1/Systems/Self/Bios/SD is:
- GET = fail / doesn't work
- PATCH = fail / doesn't work
- POST = works as expected
We are working with our server vendor to "fix this", and I was hoping there would be a way to catch this with one of the validators; but after noodling on this some more I'm worried this edge case is going to be very hard to catch.
|
|
|
|
Post by mraineri on May 8, 2023 12:49:19 GMT
Thanks for confirming; I was hoping the GET would work so we could detect this... I'll leave the PR open for a bit to see if there's anything else we can try in this space.
|
|
