Error handling

Fri Sep 1 01:28:50 AEST 2023

On Thu, Aug 31, 2023 at 05:16:50PM +0530, chandu chanti wrote:
> Hi team,
> 
> We have drafted a proposal for  "Using default values in D-Bus properties
> to indicate errors"  as communicated in previous mail.
> 
> Issue with Existing Implementation:
> Error handling is not implemented in the existing bmcweb source. The values
> fetched from D-Bus are used directly in the Redfish response, except for
> some properties. There was no way to represent error for a given data type
> on Redfish.
> 
> New Implementation Proposal:
> We plan to handle errors from backend D-Bus services in bmcweb using a
> custom data type class. We will implement a helper class to create a new
> data type called mydatatype_t. An object of this class will be created with
> the D-Bus property value as input. This object will be assigned to the JSON
> response using the assignment operator. This assignment operation will
> invoke the to_json function with the mydatatype_t object, where D-Bus
> values will be validated based on their data types.

I don't understand the proposal.  Is this something contained to bmcweb,
or does it affect other repos?  sdbusplus also, or just the backend
applications?  I am unable to translate what you've written to dbus property
and/or method behaviors.

> 
> Data Types and Default Values:
> The following values will be set on the D-Bus property in case of an error,
> based on the data type. In Redfish, we will validate these properties. If
> the D-Bus property value matches the error value, we will update the
> property value as null in the Redfish JSON response; otherwise, the
> corresponding value on D-Bus will be used.
> 

Is the below intended to be a table?  I can't figure out what this long
list of types and values is suppose to be.

> *D-Bus*
> 
> *data type*
> 
> *Value of the D-Bus Property incase of Error *
> 
> *Property value as seen on Redfish *
> 
> INT16
> 
> INT_MAX
> 
> null
> 
> UINT16
> 
> UINT_MAX
> 
> null
> 
> INT32
> 
> LONG_MAX
> 
> null
> 
> UINT32
> 
> ULONG_MAX
> 
> null
> 
> INT64
> 
> LLONG_MAX
> 
> null
> 
> UINT64
> 
> ULLONG_MAX
> 
> null
> 
> DOUBLE
> 
> std::numeric_limits <http://en.cppreference.com/w/cpp/types/numeric_limits>
> <T>::quiet_NaN()
> 
> null
> 
> STRING
> 
> BE_ERROR-XXX
> 
> null
> 
> BOOL
> 
> uint8_t
> {0–false , 1–true,
>   others- error}
> 
> null
> 
> In case of error conditions Redfish will report "null" for a property
> irrespective  of the data type.
> 
> For error validation, we will implement a custom class, which will
> facilitate error validation for D-Bus values. In instances of errors, a
> null value will be allocated to the JSON response. Example for the uint16_t
> data type.
> 
> [image: image.png]
> 
> [image: image.png]
> 
> For more implementation details please refer the following gerrit link, we
> implemented it for redfish URI /redfish/v1/Systems/<str>/Memory/<str>/.
> https://gerrit.openbmc.org/c/openbmc/bmcweb/+/66368
> 
> Your feedback and insights are greatly appreciated.
> 
> Thanks,
> Chandrasekhar T.
> 
> On Fri, Aug 4, 2023 at 12:37 PM Shakeeb Pasha <shakeebbk at gmail.com> wrote:
> 
> > Thanks Joseph for the response.
> > >> I didn't see anyone else answer this.  Is your question about how to
> > >> architect or design your D-Bus interfaces?  Is the reference the BMCWeb
> > >> merely to provide context as a consumer of these D-Bus services?  I
> > >> assume so.
> > Question is two pronged, one we wanted to know the best way to
> > propagate error from dbus to bmcweb.
> > Options we tried:
> > 1. Have handlers of each property throw an exception if there was an
> > error. But this did not work well with current bmcweb implementation(get
> > all method call), as it would lead to the entire resource not getting
> > populated even if we have one property failing.
> > 2. Implement one additional associated rc property - and do the error
> > handling bmcweb by looking at that, but this doubled up the number of
> > properties on dbus.
> > 3. Use "default values" per property data type, but this would fail for
> > extreme cases like if the property is u32, and if the default value used
> > was INT_MAX, then it breaks when the property could take value 0xFFFFFFFF
> > as valid value.
> > So the query here was to check if any preference from above options or
> > hear any new approaches as well.
> >
> > The second query was about how to represent this error(per property error)
> > on redfish, our proposal for now is to return "NULL" for any property that
> > might be failing at the backend. Any thoughts on this approach?
> >
> > >> I don't have any special insights.  Are you looking to follow a design
> > >> pattern?  Are you looking for direction from the BMCWeb maintainers?
> >
> > Yes, we are working on a design pattern proposal and will publish it here
> > for review.
> > It would be great if we could get some directions/inputs from the
> > maintainers as well.
> >
> > Thanks,
> > Shakeeb
> >
> > On Thu, Aug 3, 2023 at 10:33 PM Joseph Reynolds <jrey at linux.ibm.com>
> > wrote:
> >
> >> On 7/20/23 2:04 AM, chandu chanti wrote:
> >> > Hi Team, We are planning to handle errors from backend services in bmc
> >> > web. We are considering the following approaches to implement it, but
> >> > we are facing some issues. please provide your inputs. 1 . Using
> >> > exceptions in our backend D-Bus service
> >> > ZjQcmQRYFpfptBannerStart
> >> > This Message Is From an Untrusted Sender
> >> > You have not previously corresponded with this sender.
> >> > Report Suspicious
> >> > <
> >> https://us-phishalarm-ewt.proofpoint.com/EWT/v1/PjiDSg!12-vrJJyaRL1Nus7N26ProiLa90y_FB6oawxkmvrT4YcN373bBkdTP-XPRTFLRBygswzt1TwX0wxp5Tel83pR4ZZR-wpxEYJpcKudcTfq2FH6iPLN9Ep4cV_tX4$>
> >>
> >> >
> >> > ZjQcmQRYFpfptBannerEnd
> >> >
> >> > Hi Team,
> >> >
> >> > We are planning to handle errors from backend services in bmc web. We
> >> > are considering the following approaches to implement it, but we are
> >> > facing some issues. please provide your inputs.
> >> >
> >>
> >> I didn't see anyone else answer this.  Is your question about how to
> >> architect or design your D-Bus interfaces?  Is the reference the BMCWeb
> >> merely to provide context as a consumer of these D-Bus services?  I
> >> assume so.
> >>
> >> I don't have any special insights.  Are you looking to follow a design
> >> pattern?  Are you looking for direction from the BMCWeb maintainers?
> >>
> >> Joseph
> >>
> >> > 1 . Using exceptions in our backend D-Bus service by throwing
> >> > exceptions in the D-Bus property get handlers. It works fine for the
> >> > Get property method call. However, when using the Get All method call,
> >> > if one property fails, an error is returned without checking the other
> >> > properties. Is there a way to implement exceptions in GetAll so that
> >> > even if one property fails, we can still fetch the remaining properties.
> >> >
> >> > 2. Using default values in D-Bus properties to indicate errors. Is
> >> > there a reference implementation available for setting default values
> >> > for string and integer data types in bmc web, similar to the
> >> > implementation of NaN (default value) for the double data type in
> >> > cable.hpp.
> >> >
> >> > 3. Implement associated return code per property on dbus, but this
> >> > would be very inefficient in terms of double the properties on dbus,
> >> > something we would like to avoid
> >> >
> >> > Thanks
> >> > Chandrasekhar T.
> >> >
> >>
> >>

-- 
Patrick Williams
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.ozlabs.org/pipermail/openbmc/attachments/20230831/57f05850/attachment-0001.sig>