BMC/OpenBmc/bmcweb.git, branch master

OWNERS: add myself as a reviewer

2026-09-28T05:31:51+00:00

Add myself to the bmcweb OWNERS file as a reviewer. I have been actively contributing to and reviewing bmcweb changes for more than two months. Contributions: [1] Reviews: [2] [1] https://github.com/openbmc/bmcweb/commits?author=joel-pj [2] https://gerrit.openbmc.org/q/reviewer:joelpj@ami.com Change-Id: Ibf0b3dac335aa4f76ed44b94e2fba25b75f68b04 Signed-off-by: Joel Pullokaran Jesin

OWNERS: add myself as a reviewer

2026-09-26T05:13:34+00:00

Add myself to the bmcweb OWNERS file as a reviewer. Contributions: [1][2] [1] https://github.com/openbmc/bmcweb/commits?author=Yuvakumar-Selvamani [2] https://gerrit.openbmc.org/q/owner:yuvakumars@ami.com Change-Id: Ic5f82102d6883d7de2e5725e410ab62f45fb77e7 Signed-off-by: Yuvakumar Selvamani

eventservice: Return Redfish 404 on PATCH

2026-09-25T10:13:09+00:00

Return a Redfish ResourceNotFound error for PATCH requests to an EventDestination that does not exist. Before this change, PATCH on a missing subscription returned only HTTP 404 with no Redfish error payload. That left clients without the standard error body used to identify the failing resource and the expected message registry code. After this change, PATCH /redfish/v1/EventService/Subscriptions/{Id}/ returns HTTP 404 with Base.1.19.ResourceNotFound when the requested EventDestination is not present. Tested: PATCH /redfish/v1/EventService/Subscriptions/does-not-exist/ with {} returns HTTP 404 and Base.1.19.ResourceNotFound. Redfish Service Validator for /redfish/v1/EventService/Subscriptions/ reports PASS 5, WARN 0, FAIL 0, SKIP 5. Change-Id: I84eeabc91a3b75e8a47173b99217b128506f5e8a Signed-off-by: Joel Pullokaran Jesin

ssl_key_handler: Avoid redundant c_str() call

2026-09-25T06:23:12+00:00

std::filesystem::remove() already accepts a std::filesystem::path directly. Calling certPath.c_str() first converts the path to a const char*, which is then implicitly re-converted back into a temporary path object - an unnecessary round-trip. Pass certPath directly instead. Found during review of Ia8cfbbc8eeefa6f6cc3bd8d291d93876cc869d47c (https://gerrit.openbmc.org/c/openbmc/bmcweb/+/94314), raised as a separate change per reviewer request since that change is a pure refactor already approved. Tested: - Tested on AST2600 SoC. Triggered a real hostname-change D-Bus signal (busctl set-property .../network/config xyz.openbmc_project.Network.SystemConfiguration HostName s "") to exercise installCertificate() end-to-end. journalctl -u bmcweb confirmed the fixed remove(certPath, ec2) call ran and logged "Replace HTTPs Certificate Success", and the temp file (/tmp/hostname_cert.tmp) was removed as expected. - Verified the new cert was actually installed and served: $ curl -sk -v https://BMC_IP/redfish/v1/ -o /dev/null 2>&1 | \ grep subject: * subject: C=US; O=OpenBMC; CN= - Verified Redfish still healthy post-reload: $ curl -sk -u BMC_USER:BMC_PASS \ -o /dev/null -w "HTTP %{http_code}\n" \ https://BMC_IP/redfish/v1/Managers/bmc HTTP 200 - Redfish Service Validator: 5830 Pass / 353 Warn / 0 Fail. Change-Id: If60533899dbbc84bb151e282e83f22ef636eb119 Signed-off-by: Yuvakumar Selvamani

Use enum for watchdog timeout action property

2026-09-25T03:50:53+00:00

The dbusToRfWatchdogAction() function returns the watchdog timeout action as std::string literals, which lacks compile-time type safety. This can lead to typos or invalid values that are only caught at runtime. Convert this function to return computer_system::WatchdogTimeoutActions enum instead. This enum is already defined in computer_system.hpp with NLOHMANN_JSON_SERIALIZE_ENUM mapping and provides proper type checking. The enum automatically serializes to the same JSON strings, so there is no functional change to the Redfish API. This provides compile-time type checking and better error handling through the Invalid enum value. Tested: - Verified HostWatchdogTimer TimeoutAction property serializes to identical JSON values. - RSV: PASS: 5803, WARN: 353, FAIL: 0, NOT TESTED: 4894 Change-Id: I9aa667796a5bda7eddabd7d37a211d304b39796f Signed-off-by: Vinothkumar Shanmugavel

redfish-core: Refactor TelemetryService lambda

2026-09-24T06:45:19+00:00

Extract the long D-Bus GetAllProperties callback lambda in handleTelemetryServiceGet() into a named function, afterGetTelemetryServiceProperties(), bound via std::bind_front(), per the <10 line lambda coding standard in docs/COMMON_ERRORS.md. Also updates the DBus error log message from "respHandler DBus error {}" to "afterGetTelemetryServiceProperties DBus error {}" to include the function name, per review feedback. Tested: - Verified GET /redfish/v1/TelemetryService returns identical values (MaxReports, MinCollectionInterval, Status, SupportedCollectionFunctions) to the pre-refactor lambda, with a live phosphor-telemetry backend. - Redfish Service Validator passed with a real MetricReportDefinition and MetricReport present: 0 Fail on all TelemetryService endpoints (5451 Pass / 353 Warn / 9 Fail overall; the 9 failures are pre-existing, unrelated Managers/bmc errors). Change-Id: I97733e7bedf5868625f32f2008c39b9a9b69abdd Signed-off-by: Yuvakumar Selvamani

Refactor startAsyncWaitForSignal lambda

2026-09-24T06:43:40+00:00

Extract the long signal handler lambda in startAsyncWaitForSignal() into a named member function, afterWaitForSignal(), bound via std::bind_front(), per the <10 line lambda coding standard in docs/COMMON_ERRORS.md. Tested on AST2600 SoC: - `kill -HUP `, then `GET /redfish/v1/` Expected: cert reload, service stays active, 200 OK Actual: bmcweb.service remained active, GET returned HTTP 200 - `kill -TERM ` Expected: clean shutdown Actual: journalctl confirmed "bmcweb.service: Deactivated successfully" - RSV: 5845 Pass / 353 Warn / 0 Fail Change-Id: Id02f26fd680ae34639b521962b0f4e3d67c534bc Signed-off-by: Yuvakumar Selvamani

Use the privilege entry that matches the route

2026-09-21T03:46:22+00:00

Five routes are registered with a privilege registry entry that names a different resource, or a different method, than the route serves: - certificate_service: the Truststore certificate collection GET uses getCertificate. The POST on the same URL already uses postCertificateCollection, and the LDAP and HTTPS certificate collections use getCertificateCollection. - storage_chassis: the chassis drive GET uses getChassis, although the handler serves a Drive resource and the collection above it uses getDriveCollection. - redfish_v1: the JsonSchemas collection and a single JsonSchemaFile hold each other's entry. - metric_report_definition and aggregation_service: two HEAD routes use the get* entry where the head* entry exists. Every one of these pairs resolves to the same privilege set today, so no client sees a change. They are corrected so the routes stay right if the registry ever distinguishes a pair, and so the next reader can trust the entry name. Tested: Redfish Service Validator against a cypress BMC image carrying this change, and again against one without it: both pass, with no failures and identical warning and error counts. The routes this touches were traversed in both runs, bar AggregationSources, which that build does not register. Verified that each replacement entry exists in redfish-core/include/registries/privilege_registry.hpp, that the resource type matches what the handler serves, for example storage_chassis emits #Drive.v1_7_0.Drive, and that every changed pair resolves to the same privilege set as before: getCertificate and getCertificateCollection are both privilegeSetConfigureManager, while the JsonSchemaFile pair and both HEAD pairs are privilegeSetLogin. No client-visible behavior changes as a result. Change-Id: Ib06a2f0e0a43dcfe1fbc7127f6345e40c5202c5f Signed-off-by: Bill Chan

Report rejected action values with ValueNotInList

2026-09-21T02:59:20+00:00

Manager.Reset, Manager.ResetToDefaults, Chassis.Reset and UpdateService.SimpleUpdate reject an unsupported parameter value with Base.1.19.ActionParameterNotSupported. That message reads "The parameter %1 for the action %2 is not supported on the target resource", and its resolution tells the client to remove the parameter and resubmit. ResetType and TransferProtocol are required parameters of those actions, so the client cannot act on that advice. The arguments were also passed in the wrong order, putting the submitted value where the parameter name belongs. All four parameters are published enumerations: ResetType through the ResetActionInfo resources and the ResetType@Redfish.AllowableValues annotation, TransferProtocol through TransferProtocol@Redfish.AllowableValues. A value outside those lists is Base.1.19.ActionParameterValueNotInList, which names the parameter, the value and the action, and tells the client to choose a supported value. This is the same correction commit 191526da made for ComputerSystem.Reset. The action argument carries the qualified action name, as it appears in the action's target URI and in the existing UpdateService.SimpleUpdate calls in update_service.hpp. Tested: Verified on a QEMU BMC, machine cypress, running a downstream OpenBMC build carrying this change. POST /redfish/v1/Managers/bmc/Actions/Manager.Reset with {"ResetType":"Nope"} returns HTTP 400 and Base.1.19.ActionParameterValueNotInList with MessageArgs ["Nope", "ResetType", "Manager.Reset"]. POST /redfish/v1/Managers/bmc/Actions/Manager.ResetToDefaults with the same body returns HTTP 400 and the same MessageId with MessageArgs ["Nope", "ResetType", "Manager.ResetToDefaults"]. POST /redfish/v1/Chassis//Actions/Chassis.Reset with the same body returns HTTP 400 and MessageArgs ["Nope", "ResetType", "Chassis.Reset"]. The UpdateService.SimpleUpdate site was not exercised: that build has redfish-allow-simple-update disabled, so the action is not registered. Change-Id: I2db0ddd1cec4d7efe512fe43d8ac7d85d112ab52 Signed-off-by: Bill Chan

Report the property the request actually failed on

2026-09-21T02:59:01+00:00

Three error paths name a property or condition that has nothing to do with the failure, so a client cannot tell what to correct. - account_service: a RoleId that maps to no privilege reports PropertyValueNotInList for Locked with the value true. RoleId is the property that was rejected, and its submitted value is what the client needs to see. - systems: a PATCH of TrustedModuleRequiredToBoot on a system with no TPM.Policy object reports PropertyValueNotInList with the value "ComputerSystem", which is neither a submitted value nor an enumeration member. Nothing is wrong with the value; the property cannot be written on this system, which is PropertyNotWritable. - openbmc_managers: Direction is checked against the enumeration {Ceiling, Floor}, so a rejected value is PropertyValueNotInList, not PropertyValueTypeError. The arguments were also reversed, since PropertyValueTypeError takes the value first. Tested: Verified on a QEMU BMC, machine cypress, running a downstream OpenBMC build carrying this change. PATCH /redfish/v1/AccountService/Accounts/root with {"RoleId":"Bogus"} returns HTTP 400 and Base.1.19.PropertyValueNotInList with MessageArgs ["\"Bogus\"", "RoleId"], where the same request previously reported Locked with the value true. Not exercised on that build: the TrustedModuleRequiredToBoot site, because that platform has a TPM.Policy object so the empty-subtree branch never runs; and the OEM fan Direction site, because the machine exposes no PID or stepwise fan controllers to PATCH. Change-Id: I408456a7040f095b43a952532f761ec197c24146 Signed-off-by: Bill Chan