Error handling
chandu chanti
chandutmba at gmail.com
Sat Sep 2 00:25:28 AEST 2023
>I don't understand the proposal. Is this something contained within
bmcweb, or does it affect other repositories?
>Does it also affect sdbusplus, or is it limited to the backend
applications?
>I am unable to interpret your writing in terms of dbus property and/or
method behaviors.
yes We require changes in the backend dbus service; sdbusplus changes are
not required.
Implementation details for the backend dbus service are as follows:
All dbus properties will use the values mentioned in the table as
representations of error values.
For string data types, we will use the predefined value "BE_ERROR-XXX” to
indicate error conditions.
For double data types, we will use "nan" to represent error conditions.
For all integer data types, we will use the corresponding MAX values based
on the data type.
>Regarding the content below, is it intended to be presented as a table?
>I'm having trouble understanding what this extensive list of types and
values is meant to convey.
Yes, it's a table. There seems to be an issue with formatting. We have
organized all data types in a table.
Error represenation Table for different data types
| D-Bus Data Type | Value of the D-Bus Property in case 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<T>::quiet_NaN() | null
|
| STRING | BE_ERROR-XXX | null
|
| BOOL | uint8_t {0–false, 1–true, others- error} | null
|
On Thu, Aug 31, 2023 at 8:58 PM Patrick Williams <patrick at stwcx.xyz> wrote:
> 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 --------------
An HTML attachment was scrubbed...
URL: <http://lists.ozlabs.org/pipermail/openbmc/attachments/20230901/6ef75ea3/attachment.htm>
More information about the openbmc
mailing list