rf_sys_inventory.py fails to find Baseboard

[StackKorora]

Not sure if this is a bad spec or what, but Intel has a sub-folder for Baseboard. A nicer error handling would be nice here at least but perhaps recognizing the Intel Baseboard is under RackMount would be better.

$ rf_sys_inventory.py -u myuser -p mypass -r https://my.ip.add 
Traceback (most recent call last):
  File "/home/user/miniconda3/envs/redfish/bin/rf_sys_inventory.py", line 39, in <module>
    inventory = redfish_utilities.get_system_inventory( redfish_obj )
  File "/home/user/miniconda3/envs/redfish/lib/python3.7/site-packages/redfish_utilities/inventory.py", line 69, in get_system_inventory
    verify_response( chassis )
  File "/home/user/miniconda3/envs/redfish/lib/python3.7/site-packages/redfish_utilities/messages.py", line 71, in verify_response
    raise RedfishOperationFailedError( "Operation failed: HTTP {}\n{}".format( response.status, exception_string ) )
redfish_utilities.messages.RedfishOperationFailedError: Operation failed: HTTP 404
A general error has occurred. See ExtendedInfo for more information.
The resource at the URI /redfish/v1/Chassis/Baseboard was not found.

/redfish/v1/Chassis/ has this:

{
  "@odata.context": "/redfish/v1/$metadata#ChassisCollection.ChassisCollection",
  "@odata.id": "/redfish/v1/Chassis",
  "@odata.type": "#ChassisCollection.ChassisCollection",
  "Name": "Chassis Collection",
  "Members@odata.count": 9,
  "Members": [
    {
      "@odata.id": "/redfish/v1/Chassis/RackMount"
    },
    {
      "@odata.id": "/redfish/v1/Chassis/RackMount/Baseboard"
    },
    {
      "@odata.id": "/redfish/v1/Chassis/RackMount/HSBackplane1"
    },
    {
      "@odata.id": "/redfish/v1/Chassis/RackMount/OCPModule"
    },
    {
      "@odata.id": "/redfish/v1/Chassis/RackMount/PCIeRiser1"
    },
    {
      "@odata.id": "/redfish/v1/Chassis/RackMount/PCIeRiser2"
    },
    {
      "@odata.id": "/redfish/v1/Chassis/RackMount/AICInterposer"
    },
    {
      "@odata.id": "/redfish/v1/Chassis/RackMount/PwrSupply1FRU"
    },
    {
      "@odata.id": "/redfish/v1/Chassis/RackMount/PwrSupply2FRU"
    }
  ],
  "@odata.etag": "dd9ffd6a2c507be7fc09807cd6983d587a7f62cf3912f0d3c2d3e4ba834478f60835742d04c6d058cbd7d4c1e783ff9e19fba8bcaccbcbb771f8f3c9537edf91"
}

This is with new Intel systems. https://www.intel.com/content/www/us/en/products/sku/214845/intel-server-system-m50cyp1ur204/specifications.html

Thanks!

[mraineri]

There's an optimization done by Tacklebox to construct URIs based off the found members so it doesn't need to get each member for searching the collection. The URIs presented by the service are non-conformant and violate the spec (as of version 1.6.0). This needs to be corrected by the vendor.

[StackKorora]

Hrm. That stinks. One, it's Intel... one would hope they'd have the spec right. And two, the Redfish version is 1.7.0. :-/ I suppose then this is just a "can't fix" issue? If so, feel free to close it. Thanks!

[mraineri]

There might be a new option we can add to the tools. We've added a "workaround" flag on some the scripts that sets a variable in the module; we might be able to add something like "don't assume URIs" when traversing collections.

[StackKorora]

Thanks. I am still learning about Redfish. Can you help point me to where this is a non-conformant spec? I'm looking here: https://redfish.dmtf.org/schemas/DSP0266_1.7.0.html

I see that 6.1 defines the URI but what I don't see is the specification for a hierarchy of where things are supposed to be. Maybe under 9.4.7. Structured properties ?

I'm looking to see how these are breaking the spec so I can send an informed bug report to Intel. Thanks!

[StackKorora]

Also, do you know if there are plans to update your URI validator? https://github.com/DMTF/Redfish-URI-Validator

[mraineri]

The spec language (in version 1.7.0) of the spec is found in "9.12.4. Resource URI Patterns annotation". The only legal pattern we have for Chassis resources is "/redfish/v1/Chassis/{ChassisId}", so the system you're using has an extra URI segment in all but the first member.

The URI validation portion has actually been integrated in the Redfish-Service-Validator (which also does all of the payload checking). The URI validator should still work as-is as far as I know though, so you should be able to see errors flagged when using it against that service.

[StackKorora]

Thanks for the information. Still wrapping my head around it all. :sweat_smile: Having some issues with the Validator throwing errors in Python after using the setup.py install, but I can poke at it later when I get time.