| commit | 9d832618c74052bd445d6e8b3461946f3c431ca3 | [log] [tgz] |
|---|---|---|
| author | zhanghch05 <zhanghch05@inspur.com> | Wed Oct 20 16:04:48 2021 +0800 |
| committer | Ed Tanous <ed@tanous.net> | Wed Oct 27 20:26:05 2021 +0000 |
| tree | 302f7364ac8225d9e08e7b5d3748b35afb6a800f | |
| parent | 2107fe1809bf71cd72bdaf21e432d96b3dccc630 [diff] |
Use AsyncResp in retrieveUriToDbusMap
Initially, when the change to use AsyncResp everywhere was made, the
retrieveUriToDbusMap was skipped. This commit address that issue, by
adding AsyncResp to retrieveUriToDbusMap.
Tested:
curl -k -H "X-Auth-Token: $token" -X POST
https://${bmc}/redfish/v1/TelemetryService/MetricReportDefinitions/
-d '{"Id": "lxw1", "Metrics": [{"MetricId": "123",
"MetricProperties": ["/redfish/v1/Chassis/chassis/Power#/Voltages/0
/ReadingVolts"]}], "MetricReportDefinitionType": "OnRequest",
"ReportActions": ["LogToMetricReportsCollection"], "Schedule":
{"RecurrenceInterval": "100"}}'
{
"@Message.ExtendedInfo": [
{
"@odata.type": "#Message.v1_1_1.Message",
"Message": "The resource has been created successfully",
"MessageArgs": [],
"MessageId": "Base.1.8.1.Created",
"MessageSeverity": "OK",
"Resolution": "None"
}
],
"@odata.id": "/redfish/v1/Chassis/chassis/Power",
"@odata.type": "#Power.v1_5_2.Power",
"Id": "Power",
"Name": "Power",
"Redundancy": [],
"Voltages": [
{
"@odata.id": "/redfish/v1/Chassis/chassis/Power#/Voltages/0",
"@odata.type": "#Power.v1_0_0.Voltage",
"LowerThresholdCritical": 10.8,
"LowerThresholdNonCritical": 11.16,
"MaxReadingRange": 12600.0,
"MemberId": "P12V",
"MinReadingRange": 11400.0,
"Name": "P12V",
"ReadingVolts": 22.930140000000005,
"Status": {
"Health": "Critical",
"State": "Enabled"
},
"UpperThresholdCritical": 13.200000000000001,
"UpperThresholdNonCritical": 12.84
},
...
The response is too long, so I omitted the following content.
Signed-off-by: zhanghaicheng <zhanghch05@inspur.com>
Change-Id: I6f82bdb234ddade67f689d79d004d672593fba4f
This component attempts to be a "do everything" embedded webserver for openbmc.
At this time, the webserver implements a few interfaces:
BMCWeb is configured by setting -D flags that correspond to options in bmcweb/meson_options.txt and then compiling. For example, meson <builddir> -Dkvm=disabled ... followed by ninja in build directory. The option names become C++ preprocessor symbols that control which code is compiled into the program.
meson builddir ninja -C builddir
meson builddir -Dbuildtype=minsize -Db_lto=true -Dtests=disabled ninja -C buildir
If any of the dependencies are not found on the host system during configuration, meson automatically gets them via its wrap dependencies mentioned in bmcweb/subprojects.
meson builddir -Dwrap_mode=nofallback ninja -C builddir
meson builddir -Dbuildtype=debug ninja -C builddir
meson builddir -Db_coverage=true -Dtests=enabled ninja coverage -C builddir test
When BMCWeb starts running, it reads persistent configuration data (such as UUID and session data) from a local file. If this is not usable, it generates a new configuration.
When BMCWeb SSL support is enabled and a usable certificate is not found, it will generate a self-sign a certificate before launching the server. The keys are generated by the secp384r1 algorithm. The certificate
C=US, O=OpenBMC, CN=testhost,SHA-256 algorithm.