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

[Gunnar Mills]

On 4/13/2023 6:59 AM, Aishwary Joshi wrote:
> 
> 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.

When a client queries a Redfish resource collection with no 
corresponding D-Bus objects, the resource collection is empty. This 
isn't enough?
https://github.com/openbmc/bmcweb/blob/master/redfish-core/lib/cable.hpp#L125

I am open to doing something here, but it is extra code, so I want to 
ensure it is needed. Would we do this for all Redfish resources? Only 
select resources? How do we determine which ones?

> 
> *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


Another choice is to look at if there aren't any corresponding  D-Bus 
objects; the link is left off. E.g., in service_root.hpp, look for 
xyz.openbmc_project.Inventory.Item.Cable to determine if 
asyncResp->res.jsonValue["Cables"]["@odata.id"] = "/redfish/v1/Cables"; 
is there. This does mean extra calls in service_root.hpp


> 
> *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.
> 

Yeah, I think we should use associations for Redfish Links. We have been 
documenting associations in PDI. I think that is a great place to start.

E.g. 
https://github.com/openbmc/phosphor-dbus-interfaces/commit/36b527af49cf87d0bc7097ea6faba4904fbf8878

https://github.com/openbmc/bmcweb/issues/225 is an issue for the reverse 
Link (System to Chassis)

Thanks,
Gunnar