Error handling

[Shakeeb Pasha]

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.
> >
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ozlabs.org/pipermail/openbmc/attachments/20230804/406a52c1/attachment.htm>