| commit | 98be3e394a78f8866e731019b1828419dc66561a | [log] [tgz] |
|---|---|---|
| author | Ed Tanous <edtanous@google.com> | Thu Sep 16 15:05:36 2021 -0700 |
| committer | Ed Tanous <ed@tanous.net> | Mon Dec 06 23:50:55 2021 +0000 |
| tree | a7254f7a369a2be61de9303b32491d092cfd6e39 | |
| parent | 6a3e2913e834a4b337138ac355ca1a59b3171445 [diff] |
Remove copies from log services and virtual media
Both of these entries make complete copies of the Request object.
Following the pattern in the prior commit, move these to more modern
patterns.
For log service, this simply means constructing a payload object
earlier.
For virtual media, it means doing the readJson call and parameter
validation much earlier, which generally is the pattern we should strive
for, validating and unpacking the structs in the first scope, then
dealing with them as structures. To do this, this commit also creates a
secondary struct to store the param data in to make the lambdas cleaner.
Tested:
From Ashmitha
POST https://${bmc}/redfish/v1/Managers/bmc/LogServices/Dump/Actions/LogService.CollectDiagnosticData -d '{"DiagnosticDataType":"Manager"}'
{
"@odata.id": "/redfish/v1/TaskService/Tasks/0",
"@odata.type": "#Task.v1_4_3.Task",
"Id": "0",
"TaskState": "Running",
"TaskStatus": "OK"
}
-----------------------------------------------------------------
On task completion:
GET https://${bmc}/redfish/v1/TaskService/Tasks/0
{
"@odata.id": "/redfish/v1/TaskService/Tasks/0",
"@odata.type": "#Task.v1_4_3.Task",
"EndTime": "2021-12-03T13:40:58+00:00",
"Id": "0",
"Messages": [
{
"@odata.type": "#Message.v1_0_0.Message",
"Message": "The task with id 0 has started.",
"MessageArgs": [
"0"
],
"MessageId": "TaskEvent.1.0.1.TaskStarted",
"Resolution": "None.",
"Severity": "OK"
},
{
"@odata.type": "#Message.v1_1_1.Message",
"Message": "Successfully Completed Request",
"MessageArgs": [],
"MessageId": "Base.1.8.1.Success",
"MessageSeverity": "OK",
"Resolution": "None"
}
],
"Name": "Task 0",
"Payload": {
"HttpHeaders": [
"Host: 9.3.29.238",
"User-Agent: curl/7.71.1",
"Accept: */*",
"Content-Length: 32",
"Location: /redfish/v1/Managers/bmc/LogServices/Dump/Entries/32"
],
"HttpOperation": "POST",
"JsonBody": "{\n \"DiagnosticDataType\": \"Manager\"\n}",
"TargetUri": "/redfish/v1/Managers/bmc/LogServices/Dump/Actions/LogService.CollectDiagnosticData"
},
"PercentComplete": 0,
"StartTime": "2021-12-03T13:38:20+00:00",
"TaskMonitor": "/redfish/v1/TaskService/Tasks/0/Monitor",
"TaskState": "Completed",
"TaskStatus": "OK"
}
Signed-off-by: Ed Tanous <edtanous@google.com>
Change-Id: I178a3a7a7b27dfd34ec50a06398ac243a9d4ab67
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.