summaryrefslogtreecommitdiff
path: root/test
diff options
context:
space:
mode:
authorEd Tanous <ed@tanous.net>2024-02-14 01:43:34 +0300
committerAsmitha Karunanithi <asmitk01@in.ibm.com>2024-03-28 22:50:43 +0300
commitd02aad3988620c648d6e696b67d6c542857f5bfc (patch)
tree3da513c4a205709519d7c360d4cf56df46917a66 /test
parentf0b59af46a6aa84890d2181b08d4e1af5ce5002f (diff)
downloadbmcweb-d02aad3988620c648d6e696b67d6c542857f5bfc.tar.xz
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>
Diffstat (limited to 'test')
-rw-r--r--test/redfish-core/include/utils/dbus_utils.cpp74
1 files changed, 74 insertions, 0 deletions
diff --git a/test/redfish-core/include/utils/dbus_utils.cpp b/test/redfish-core/include/utils/dbus_utils.cpp
new file mode 100644
index 0000000000..00c53dec7f
--- /dev/null
+++ b/test/redfish-core/include/utils/dbus_utils.cpp
@@ -0,0 +1,74 @@
+
+#include "utils/dbus_utils.hpp"
+
+#include "http_request.hpp"
+#include "http_response.hpp"
+
+#include <boost/beast/http/status.hpp>
+#include <nlohmann/json.hpp>
+
+#include <cstdint>
+#include <optional>
+#include <string>
+#include <system_error>
+#include <vector>
+
+#include <gmock/gmock.h>
+#include <gtest/gtest.h>
+
+namespace redfish::details
+{
+namespace
+{
+
+TEST(DbusUtils, AfterPropertySetSuccess)
+{
+ std::shared_ptr<bmcweb::AsyncResp> asyncResp =
+ std::make_shared<bmcweb::AsyncResp>();
+
+ boost::system::error_code ec;
+ sdbusplus::message_t msg;
+ afterSetProperty(asyncResp, "MyRedfishProperty",
+ nlohmann::json("MyRedfishValue"), ec, msg);
+
+ EXPECT_EQ(asyncResp->res.result(), boost::beast::http::status::no_content);
+ EXPECT_TRUE(asyncResp->res.jsonValue.empty());
+}
+
+TEST(DbusUtils, AfterPropertySetInternalError)
+{
+ std::shared_ptr<bmcweb::AsyncResp> asyncResp =
+ std::make_shared<bmcweb::AsyncResp>();
+
+ boost::system::error_code ec =
+ boost::system::errc::make_error_code(boost::system::errc::timed_out);
+ sdbusplus::message_t msg;
+ afterSetProperty(asyncResp, "MyRedfishProperty",
+ nlohmann::json("MyRedfishValue"), ec, msg);
+
+ EXPECT_EQ(asyncResp->res.result(),
+ boost::beast::http::status::internal_server_error);
+ EXPECT_EQ(asyncResp->res.jsonValue.size(), 1);
+ using nlohmann::literals::operator""_json;
+
+ EXPECT_EQ(asyncResp->res.jsonValue,
+ R"({
+ "error": {
+ "@Message.ExtendedInfo": [
+ {
+ "@odata.type": "#Message.v1_1_1.Message",
+ "Message": "The request failed due to an internal service error. The service is still operational.",
+ "MessageArgs": [],
+ "MessageId": "Base.1.16.0.InternalError",
+ "MessageSeverity": "Critical",
+ "Resolution": "Resubmit the request. If the problem persists, consider resetting the service."
+ }
+ ],
+ "code": "Base.1.16.0.InternalError",
+ "message": "The request failed due to an internal service error. The service is still operational."
+ }
+ })"_json);
+}
+
+} // namespace
+} // namespace redfish::details