| commit | 7cf436c913a109c0d3ebf7e696970966500bc6b6 | [log] [tgz] |
|---|---|---|
| author | Ed Tanous <edtanous@google.com> | Tue Mar 22 23:53:51 2022 -0700 |
| committer | Ed Tanous <ed@tanous.net> | Tue Apr 05 18:50:46 2022 +0000 |
| tree | 395401354b8ea67abd0ce20a769af9f584b74a55 | |
| parent | f4c99e70dad320abf84fd25a32ad5fce2bf16f4a [diff] |
Implement Expand Section 7.3 of the Redfish specification lays out a feature called "expand" that allows users to expand portions of the Redfish tree automatically on the server side. This commit implements them to the specification. To accomplish this, a new class, MultiAsyncResp is created, that allows RAII objects to handle lifetime properly. When an expand query is generated, a MultiAsyncResp object is instantiated, which allows "new" requests to attach themselves to the multi object, and keep the request alive until they all complete. This also allows requests to be created, while requests are in flight, which is required for queries above depth=1. Negatives: Similar to the previous $only commit, this requires that all nodes redfish nodes now capture App by reference. This is common, but does interfere with some of our other patterns, and attempts to improve the syntactic sugar for this proved unworkable. This commit only adds the above to service root and Computer systems, in hopes that we find a better syntax before this merges. Left to future patches in series: Merging the error json structures in responses. The Redfish spec isn't very clear on how errors propagate for expanded queries, and in a conforming we shouldn't ever hit them, but nonetheless, I suspect the behavior we have is sub-optimal (attaching an error node to every place in the tree that had an issue) and we should attempt to do better in the future. Tested (on previous patch): curl --insecure --user root:0penBmc https://localhost:18080/redfish/v1\?\$expand\=.\(\$levels\=255\) Returns the full tree Setting $levels=1 query returns only a depth of 1 tree being returned. Unit tests passing Signed-off-by: Ed Tanous <edtanous@google.com> Change-Id: I874aabfaa9df5dbf832a80ec62ae65369284791d
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 -C builddir test ninja -C builddir coverage
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.