Allow configuring "bmc" and "system"
In the early days of bmcweb, we made two pretty critical assumptions;
First, is that a given platform would only have a single BMC instance
(represented as "bmc") and a single host instance (represented as
"system").
Second we assumed that, given that Redfish suggests against hardcoding
URIs in client implementation and leaves them freeform, clients would
code to the standard.
Our own webui-vue hardcodes Redfish URIs [1], and the documentation is
littered with examples of hardcoded curl examples of hardcoding these
URIs. That bug was filed in 2020, and the issue has only gotten worse
over time.
This patchset is an attempt to give a target that we can start solving
these issues, without trying to boil the ocean and fix all clients in
parallel.
This commit adds the meson options
redfish-manager-uri-name
and
redfish-system-uri-name
These are used to control the "name" that bmcweb places in the fixed
locations in the ManagerCollection and ComputerSystemCollection schemas.
Note, managers is added, but is not currently testable. It will be
iterated on over time.
Tested:
Changed the URL options to "edsbmc" and "edssystem" in meson options.
Redfish service validator passes.
URLs appear changed when walking the tree.
[1] https://github.com/openbmc/webui-vue/issues/43
Change-Id: I4b44685067051512bd065da8c2e3db68ae5ce23a
Signed-off-by: Ed Tanous <ed@tanous.net>
diff --git a/redfish-core/lib/service_root.hpp b/redfish-core/lib/service_root.hpp
index 2fc3515..fcaee98 100644
--- a/redfish-core/lib/service_root.hpp
+++ b/redfish-core/lib/service_root.hpp
@@ -89,7 +89,8 @@
asyncResp->res.jsonValue["Cables"]["@odata.id"] = "/redfish/v1/Cables";
asyncResp->res.jsonValue["Links"]["ManagerProvidingService"]["@odata.id"] =
- "/redfish/v1/Managers/bmc";
+ boost::urls::format("/redfish/v1/Managers/{}",
+ BMCWEB_REDFISH_MANAGER_URI_NAME);
nlohmann::json& protocolFeatures =
asyncResp->res.jsonValue["ProtocolFeaturesSupported"];