<div dir="ltr">>I don't understand the proposal. Is this something contained within bmcweb, or does it affect other repositories? <br>>Does it also affect sdbusplus, or is it limited to the backend applications? <br>>I am unable to interpret your writing in terms of dbus property and/or method behaviors.<br><br>yes We require changes in the backend dbus service; sdbusplus changes are not required.<br><br>Implementation details for the backend dbus service are as follows:<br><br>All dbus properties will use the values mentioned in the table as representations of error values.<br>For string data types, we will use the predefined value "BE_ERROR-XXX” to indicate error conditions.<br>For double data types, we will use "nan" to represent error conditions.<br>For all integer data types, we will use the corresponding MAX values based on the data type.<br><br>>Regarding the content below, is it intended to be presented as a table? <br>>I'm having trouble understanding what this extensive list of types and values is meant to convey.<br><br>Yes, it's a table. There seems to be an issue with formatting. We have organized all data types in a table.<br>Error represenation Table for different data types<br>| D-Bus Data Type | Value of the D-Bus Property in case of Error | Property Value as seen on Redfish |<br>|-----------------|---------------------------------------------|----------------------------------|<br>| INT16           | INT_MAX                                     | null                             |<br>| UINT16          | UINT_MAX                                    | null                             |<br>| INT32           | LONG_MAX                                    | null                             |<br>| UINT32          | ULONG_MAX                                   | null                             |<br>| INT64           | LLONG_MAX                                   | null                             |<br>| UINT64          | ULLONG_MAX                                  | null                             |<br>| DOUBLE          | std::numeric_limits<T>::quiet_NaN()        | null                             |<br>| STRING          | BE_ERROR-XXX                                | null                             |<br>| BOOL            | uint8_t {0–false, 1–true, others- error}    | null                             |<br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Aug 31, 2023 at 8:58 PM Patrick Williams <<a href="mailto:patrick@stwcx.xyz">patrick@stwcx.xyz</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Thu, Aug 31, 2023 at 05:16:50PM +0530, chandu chanti wrote:<br>
> Hi team,<br>
> <br>
> We have drafted a proposal for  "Using default values in D-Bus properties<br>
> to indicate errors"  as communicated in previous mail.<br>
> <br>
> Issue with Existing Implementation:<br>
> Error handling is not implemented in the existing bmcweb source. The values<br>
> fetched from D-Bus are used directly in the Redfish response, except for<br>
> some properties. There was no way to represent error for a given data type<br>
> on Redfish.<br>
> <br>
> New Implementation Proposal:<br>
> We plan to handle errors from backend D-Bus services in bmcweb using a<br>
> custom data type class. We will implement a helper class to create a new<br>
> data type called mydatatype_t. An object of this class will be created with<br>
> the D-Bus property value as input. This object will be assigned to the JSON<br>
> response using the assignment operator. This assignment operation will<br>
> invoke the to_json function with the mydatatype_t object, where D-Bus<br>
> values will be validated based on their data types.<br>
<br>
I don't understand the proposal.  Is this something contained to bmcweb,<br>
or does it affect other repos?  sdbusplus also, or just the backend<br>
applications?  I am unable to translate what you've written to dbus property<br>
and/or method behaviors.<br>
<br>
> <br>
> Data Types and Default Values:<br>
> The following values will be set on the D-Bus property in case of an error,<br>
> based on the data type. In Redfish, we will validate these properties. If<br>
> the D-Bus property value matches the error value, we will update the<br>
> property value as null in the Redfish JSON response; otherwise, the<br>
> corresponding value on D-Bus will be used.<br>
> <br>
<br>
Is the below intended to be a table?  I can't figure out what this long<br>
list of types and values is suppose to be.<br>
<br>
> *D-Bus*<br>
> <br>
> *data type*<br>
> <br>
> *Value of the D-Bus Property incase of Error *<br>
> <br>
> *Property value as seen on Redfish *<br>
> <br>
> INT16<br>
> <br>
> INT_MAX<br>
> <br>
> null<br>
> <br>
> UINT16<br>
> <br>
> UINT_MAX<br>
> <br>
> null<br>
> <br>
> INT32<br>
> <br>
> LONG_MAX<br>
> <br>
> null<br>
> <br>
> UINT32<br>
> <br>
> ULONG_MAX<br>
> <br>
> null<br>
> <br>
> INT64<br>
> <br>
> LLONG_MAX<br>
> <br>
> null<br>
> <br>
> UINT64<br>
> <br>
> ULLONG_MAX<br>
> <br>
> null<br>
> <br>
> DOUBLE<br>
> <br>
> std::numeric_limits <<a href="http://en.cppreference.com/w/cpp/types/numeric_limits" rel="noreferrer" target="_blank">http://en.cppreference.com/w/cpp/types/numeric_limits</a>><br>
> <T>::quiet_NaN()<br>
> <br>
> null<br>
> <br>
> STRING<br>
> <br>
> BE_ERROR-XXX<br>
> <br>
> null<br>
> <br>
> BOOL<br>
> <br>
> uint8_t<br>
> {0–false , 1–true,<br>
>   others- error}<br>
> <br>
> null<br>
> <br>
> In case of error conditions Redfish will report "null" for a property<br>
> irrespective  of the data type.<br>
> <br>
> For error validation, we will implement a custom class, which will<br>
> facilitate error validation for D-Bus values. In instances of errors, a<br>
> null value will be allocated to the JSON response. Example for the uint16_t<br>
> data type.<br>
> <br>
> [image: image.png]<br>
> <br>
> [image: image.png]<br>
> <br>
> For more implementation details please refer the following gerrit link, we<br>
> implemented it for redfish URI /redfish/v1/Systems/<str>/Memory/<str>/.<br>
> <a href="https://gerrit.openbmc.org/c/openbmc/bmcweb/+/66368" rel="noreferrer" target="_blank">https://gerrit.openbmc.org/c/openbmc/bmcweb/+/66368</a><br>
> <br>
> Your feedback and insights are greatly appreciated.<br>
> <br>
> Thanks,<br>
> Chandrasekhar T.<br>
> <br>
> On Fri, Aug 4, 2023 at 12:37 PM Shakeeb Pasha <<a href="mailto:shakeebbk@gmail.com" target="_blank">shakeebbk@gmail.com</a>> wrote:<br>
> <br>
> > Thanks Joseph for the response.<br>
> > >> I didn't see anyone else answer this.  Is your question about how to<br>
> > >> architect or design your D-Bus interfaces?  Is the reference the BMCWeb<br>
> > >> merely to provide context as a consumer of these D-Bus services?  I<br>
> > >> assume so.<br>
> > Question is two pronged, one we wanted to know the best way to<br>
> > propagate error from dbus to bmcweb.<br>
> > Options we tried:<br>
> > 1. Have handlers of each property throw an exception if there was an<br>
> > error. But this did not work well with current bmcweb implementation(get<br>
> > all method call), as it would lead to the entire resource not getting<br>
> > populated even if we have one property failing.<br>
> > 2. Implement one additional associated rc property - and do the error<br>
> > handling bmcweb by looking at that, but this doubled up the number of<br>
> > properties on dbus.<br>
> > 3. Use "default values" per property data type, but this would fail for<br>
> > extreme cases like if the property is u32, and if the default value used<br>
> > was INT_MAX, then it breaks when the property could take value 0xFFFFFFFF<br>
> > as valid value.<br>
> > So the query here was to check if any preference from above options or<br>
> > hear any new approaches as well.<br>
> ><br>
> > The second query was about how to represent this error(per property error)<br>
> > on redfish, our proposal for now is to return "NULL" for any property that<br>
> > might be failing at the backend. Any thoughts on this approach?<br>
> ><br>
> > >> I don't have any special insights.  Are you looking to follow a design<br>
> > >> pattern?  Are you looking for direction from the BMCWeb maintainers?<br>
> ><br>
> > Yes, we are working on a design pattern proposal and will publish it here<br>
> > for review.<br>
> > It would be great if we could get some directions/inputs from the<br>
> > maintainers as well.<br>
> ><br>
> > Thanks,<br>
> > Shakeeb<br>
> ><br>
> > On Thu, Aug 3, 2023 at 10:33 PM Joseph Reynolds <<a href="mailto:jrey@linux.ibm.com" target="_blank">jrey@linux.ibm.com</a>><br>
> > wrote:<br>
> ><br>
> >> On 7/20/23 2:04 AM, chandu chanti wrote:<br>
> >> > Hi Team, We are planning to handle errors from backend services in bmc<br>
> >> > web. We are considering the following approaches to implement it, but<br>
> >> > we are facing some issues. please provide your inputs. 1 . Using<br>
> >> > exceptions in our backend D-Bus service<br>
> >> > ZjQcmQRYFpfptBannerStart<br>
> >> > This Message Is From an Untrusted Sender<br>
> >> > You have not previously corresponded with this sender.<br>
> >> > Report Suspicious<br>
> >> > <<br>
> >> <a href="https://us-phishalarm-ewt.proofpoint.com/EWT/v1/PjiDSg!12-vrJJyaRL1Nus7N26ProiLa90y_FB6oawxkmvrT4YcN373bBkdTP-XPRTFLRBygswzt1TwX0wxp5Tel83pR4ZZR-wpxEYJpcKudcTfq2FH6iPLN9Ep4cV_tX4$" rel="noreferrer" target="_blank">https://us-phishalarm-ewt.proofpoint.com/EWT/v1/PjiDSg!12-vrJJyaRL1Nus7N26ProiLa90y_FB6oawxkmvrT4YcN373bBkdTP-XPRTFLRBygswzt1TwX0wxp5Tel83pR4ZZR-wpxEYJpcKudcTfq2FH6iPLN9Ep4cV_tX4$</a>><br>
> >><br>
> >> ><br>
> >> > ZjQcmQRYFpfptBannerEnd<br>
> >> ><br>
> >> > Hi Team,<br>
> >> ><br>
> >> > We are planning to handle errors from backend services in bmc web. We<br>
> >> > are considering the following approaches to implement it, but we are<br>
> >> > facing some issues. please provide your inputs.<br>
> >> ><br>
> >><br>
> >> I didn't see anyone else answer this.  Is your question about how to<br>
> >> architect or design your D-Bus interfaces?  Is the reference the BMCWeb<br>
> >> merely to provide context as a consumer of these D-Bus services?  I<br>
> >> assume so.<br>
> >><br>
> >> I don't have any special insights.  Are you looking to follow a design<br>
> >> pattern?  Are you looking for direction from the BMCWeb maintainers?<br>
> >><br>
> >> Joseph<br>
> >><br>
> >> > 1 . Using exceptions in our backend D-Bus service by throwing<br>
> >> > exceptions in the D-Bus property get handlers. It works fine for the<br>
> >> > Get property method call. However, when using the Get All method call,<br>
> >> > if one property fails, an error is returned without checking the other<br>
> >> > properties. Is there a way to implement exceptions in GetAll so that<br>
> >> > even if one property fails, we can still fetch the remaining properties.<br>
> >> ><br>
> >> > 2. Using default values in D-Bus properties to indicate errors. Is<br>
> >> > there a reference implementation available for setting default values<br>
> >> > for string and integer data types in bmc web, similar to the<br>
> >> > implementation of NaN (default value) for the double data type in<br>
> >> > cable.hpp.<br>
> >> ><br>
> >> > 3. Implement associated return code per property on dbus, but this<br>
> >> > would be very inefficient in terms of double the properties on dbus,<br>
> >> > something we would like to avoid<br>
> >> ><br>
> >> > Thanks<br>
> >> > Chandrasekhar T.<br>
> >> ><br>
> >><br>
> >><br>
<br>
<br>
<br>
<br>
-- <br>
Patrick Williams<br>
</blockquote></div>