<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=us-ascii">
<meta name="Generator" content="Microsoft Word 15 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
        {font-family:"Cambria Math";
        panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
        {font-family:Calibri;
        panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
        {font-family:"Abadi Extra Light";}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
        {margin:0in;
        font-size:11.0pt;
        font-family:"Calibri",sans-serif;
        mso-ligatures:standardcontextual;}
a:link, span.MsoHyperlink
        {mso-style-priority:99;
        color:#0563C1;
        text-decoration:underline;}
span.EmailStyle17
        {mso-style-type:personal-compose;
        font-family:"Calibri",sans-serif;
        color:windowtext;}
p.xmsonormal, li.xmsonormal, div.xmsonormal
        {mso-style-name:x_msonormal;
        margin:0in;
        font-size:11.0pt;
        font-family:"Calibri",sans-serif;}
.MsoChpDefault
        {mso-style-type:export-only;
        font-family:"Calibri",sans-serif;
        mso-ligatures:standardcontextual;}
@page WordSection1
        {size:8.5in 11.0in;
        margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
        {page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang="EN-US" link="#0563C1" vlink="#954F72" style="word-wrap:break-word">
<div class="WordSection1">
<p class="xmsonormal">Problem Statement<o:p></o:p></p>
<p class="xmsonormal">1. Unsupported routes getting activated on the platform<o:p></o:p></p>
<p class="xmsonormal">2. Redfish resources contain properties  which are initialized with default values which causes misleading info present on redfish interface.<o:p></o:p></p>
<p class="xmsonormal"> <o:p></o:p></p>
<p class="xmsonormal"> <o:p></o:p></p>
<p class="xmsonormal"><b>For problem #1,</b><o:p></o:p></p>
<p class="xmsonormal">We have seen that in the current bmcweb implementation, certain collection routes are enabled by default<o:p></o:p></p>
<p class="xmsonormal">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.<o:p></o:p></p>
<p class="xmsonormal"> <o:p></o:p></p>
<p class="xmsonormal"><b>Suggestion 1: Feature Flag(already present for some of the routes)</b><o:p></o:p></p>
<p class="xmsonormal">Enable/disable such routes through compile time flags for given platform.
<o:p></o:p></p>
<p class="xmsonormal"> <o:p></o:p></p>
<p class="xmsonormal">But this could make bmcweb code difficult to manage especially to support multiple platforms with varied configurations<o:p></o:p></p>
<p class="xmsonormal"> <o:p></o:p></p>
<p class="xmsonormal"> <o:p></o:p></p>
<p class="xmsonormal"><b>For problem #2</b><o:p></o:p></p>
<p class="xmsonormal">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
<span style="font-family:"Abadi Extra Light",sans-serif">Links.ComputerSystems</span> is not mandatory property as for Chassis resource these are the only required fields which we are adhering to.<o:p></o:p></p>
<p class="xmsonormal">      - ChassisType<o:p></o:p></p>
<p class="xmsonormal">      - '@odata.id'<o:p></o:p></p>
<p class="xmsonormal">      - '@odata.type'<o:p></o:p></p>
<p class="xmsonormal">      - Id<o:p></o:p></p>
<p class="xmsonormal">      - Name<o:p></o:p></p>
<p class="xmsonormal">Code Ref: <a href="https://github.com/openbmc/bmcweb/blob/master/redfish-core/lib/chassis.hpp#L456">
https://github.com/openbmc/bmcweb/blob/master/redfish-core/lib/chassis.hpp#L456</a><o:p></o:p></p>
<p class="xmsonormal">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.
<o:p></o:p></p>
<p class="xmsonormal"> <o:p></o:p></p>
<p class="xmsonormal"><b>Suggestion 2: To use d-bus based discovery checks to populate such Links/Properties instead of having any default value in the bmcweb</b><o:p></o:p></p>
<p class="xmsonormal">Dbus based discovery can be through following checks (but not limited to):<o:p></o:p></p>
<p class="xmsonormal">- dbus property checks on an interface <o:p></o:p></p>
<p class="xmsonormal">- Association checks<o:p></o:p></p>
<p class="xmsonormal">- dbus interface checks<o:p></o:p></p>
<p class="xmsonormal">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.<o:p></o:p></p>
<p class="xmsonormal"> <o:p></o:p></p>
<p class="xmsonormal">Reaching out to get the feedback on two suggestions that we have provided.
<o:p></o:p></p>
<p class="xmsonormal">Also like to understand if there is/are any other solution already exist or being worked upon to mitigate these problems.
<br>
<br>
Thanks,<br>
Aishwary<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
</body>
</html>