[Help Required]Unsupported routes and properties present on Redfish Interface

[Aishwary Joshi]

Problem Statement

1. Unsupported routes getting activated on the platform

2. Redfish resources contain properties  which are initialized with default values which causes misleading info present on redfish interface.





For problem #1,

We have seen that in the current bmcweb implementation, certain collection routes are enabled by default

Eg requestRoutesTriggerCollection, requestRoutesCableCollection etc. which are not must have routes on our platforms but gets enabled by default. We know that when redfish api for the collection will not return any member on platform where backend support is absent  but since /redfish/v1 has links to these collection routes. It creates an impression about feature is being supported and when actually its not.



Suggestion 1: Feature Flag(already present for some of the routes)

Enable/disable such routes through compile time flags for given platform.



But this could make bmcweb code difficult to manage especially to support multiple platforms with varied configurations





For problem #2

We have a use case where certain platform supports multiple redfish Chassis resource and only on few of redfish Chassis resource we want to populate Links.ComputerSystems . As per redfish schema Links.ComputerSystems is not mandatory property as for Chassis resource these are the only required fields which we are adhering to.

      - ChassisType

      - '@odata.id'

      - '@odata.type'

      - Id

      - Name

Code Ref: https://github.com/openbmc/bmcweb/blob/master/redfish-core/lib/chassis.hpp#L456

DONOT want to tie this problem statement to just Chassis resource. The example mentioned above is just one code block where we have observed the issue but exist for few of the redfish properties in other redfish resources also.



Suggestion 2: To use d-bus based discovery checks to populate such Links/Properties instead of having any default value in the bmcweb

Dbus based discovery can be through following checks (but not limited to):

- dbus property checks on an interface

- Association checks

- dbus interface checks

This would ensure that on any redfish resource there are no default values and Links/Properties are populated only when backend service actually supports it.



Reaching out to get the feedback on two suggestions that we have provided.

Also like to understand if there is/are any other solution already exist or being worked upon to mitigate these problems.

Thanks,
Aishwary

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ozlabs.org/pipermail/openbmc/attachments/20230413/acfbe4f6/attachment.htm>