commit d02aad3988620c648d6e696b67d6c542857f5bfc
author Ed Tanous <ed@tanous.net> Tue Feb 13 14:43:34 2024 -0800
committer Asmitha Karunanithi <asmitk01@in.ibm.com> Thu Mar 28 19:50:43 2024 +0000
tree 3da513c4a205709519d7c360d4cf56df46917a66
parent f0b59af46a6aa84890d2181b08d4e1af5ce5002f

Create Redfish specific setProperty call

There are currently 78 sdbusplus::asio::setProperty calls in
redfish-core.  The error handler for nearly all of them looks something
like:

```
if (ec)
{
    const sd_bus_error* dbusError = msg.get_error();
    if ((dbusError != nullptr) &&
        (dbusError->name ==
         std::string_view(
             "xyz.openbmc_project.Common.Error.InvalidArgument")))
    {
        BMCWEB_LOG_WARNING("DBUS response error: {}", ec);
        messages::propertyValueIncorrect(asyncResp->res, "<PropertyName>", <PropertyValue>);
        return;
    }
    messages::internalError(asyncResp->res);
    return;
}
messages::success(asyncResp->res);

```

In some cases there are more errors handled that translate to more error
messages, but the vast majority only handle InvalidArgument.  Many of
these, like the ones in account_service.hpp, do the error handling in a
lambda, which causes readability problems.  This commit starts to make
things more consistent, and easier for trivial property sets.

This commit invents a setDbusProperty method in the redfish namespace
that tries to handle all DBus errors in a consistent manner.  Looking
for input on whether this will work before changing over the other 73
calls.  Overall this is less code, fewer inline lambdas, and defaults
that should work for MOST use cases of calling an OpenBMC daemon, and
fall back to more generic errors when calling a "normal" dbus daemon.

As part of this, I've ported over several examples.  Some things that
might be up in the air:
1. Do we always return 204 no_content on property sets?  Today there's a
mix of 200, with a Base::Success message, and 204, with an empty body.
2. Do all DBus response codes map to the same error?  A majority are
covered by xyz.openbmc_project.Common.Error.InvalidArgument, but there
are likely differences.  If we allow any daemon to return any return
code, does that cause compatibility problems later?

Tested:
```
curl  -k --user "root:0penBmc" -H "Content-Type: application/json" -X PATCH -d '{"HostName":"openbmc@#"}' https://192.168.7.2/redfish/v1/Managers/bmc/EthernetInterfaces/eth0
```

Returns the appropriate error in the response
Base.1.16.0.PropertyValueIncorrect

Change-Id: If033a1112ba516792c9386c997d090c8f9094f3a
Signed-off-by: Ed Tanous <ed@tanous.net>