Error handling
Patrick Williams
patrick at stwcx.xyz
Sat Sep 2 11:52:13 AEST 2023
On Fri, Sep 01, 2023 at 07:55:28PM +0530, chandu chanti wrote:
> >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.
I don't think we're going to change all the backend services to follow
this proposal. The magic-values-that-mean-error that you have proposed
are actually values we use sometimes, also. How would somoeone
differentiate between an error and a valid value of these values?
>
> 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.
Maybe we should step back. Why do properties have error results? Is
this a case of a specific [upstreamed] backend, or is this just
something you're seeing in your implementation? Generally, accessing a
dbus-property should not result in an error. If we have lots of dbus
properties that are regularly resulting in an error, we should fix that.
Can you give specific examples?
>
> >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
> >
--
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/20230901/a5316d6f/attachment.sig>
More information about the openbmc
mailing list