Redfish OEM Extension for SONiC BMC with Schema Mapping to Redis & D-Bus

[chinmoy-nexthop]

Map OEM rack manager alerts/telemetry to Redis via sonic-dbus-bridge

What:

- Extend the OEM Sonic Manager schema so SONiC.SubmitAlert and SONiC.SubmitTelemetry carry structured, extensible payloads:
  - SubmitAlert now accepts a redfish_alert_data object keyed by alert type (FlowRateDeviation, LeakDetected, etc.), each with its own fields plus Severity and RscmPosition.
  - SubmitTelemetry now accepts an Alarms object containing sensor status flags, deviation sub-objects, leak detection, and general parameters.
- Update OEM bmcweb actions (SONiC.SubmitAlert / SONiC.SubmitTelemetry) to validate the new JSON shapes and forward the raw JSON to sonic-dbus-bridge over D-Bus instead of parsing individual fields.
- Add a RackManagerReceiver component and declarative field-mapping tables in sonic-dbus-bridge to map OEM JSON into Redis STATE_DB keys/fields.
- Refine Makefile clean/reset targets and Docker build flow for the OEM branch to ensure a fully reproducible workspace.

Why:

- Provide a flexible OEM schema for rack manager alerts and telemetry that can evolve without changing core bmcweb or bridge logic.
- Centralize the JSON→Redis mapping in sonic-dbus-bridge so bmcweb remains a thin HTTP/D-Bus adapter and internal field names are defined in one place.
- Persist rack manager data in STATE_DB in a structured way (RSCM_TELEMETRY|alarms, RSCM_ALERT|<AlertType> hashes) for later consumption by monitoring, analytics, or policy components.
- Make OEM builds more reliable by cleaning all Docker images, build artifacts, and cloned bmcweb state between runs.

How:

- oem-extension schema:
  - Change `SonicManager.v1_0_0.json`:
    - SubmitAlert:
      - Replace flat `AlertType` / `Severity` / `Message` body with `redfish_alert_data` (object, additionalProperties = AlertEntry).
      - Introduce `AlertEntry` definition with required `Severity` and `RscmPosition`, allowing additional per-alert-type fields.
    - SubmitTelemetry:
      - Replace individual scalar fields (InletLiquidTemperatureCelsius, FlowRate, Pressure, LeakDetected) with an `Alarms` object.
      - Add nested structures for InletTempDeviation, FlowRateDeviation, LiquidPressureDeviation, LeakDetected, plus status flags and general parameters.
- bmcweb OEM actions:
  - `sonic_submit_alert.hpp`:
    - Drop json_utils-based field extraction.
    - Parse the request body as JSON, require `redfish_alert_data`, and log payload size.
    - Forward the raw JSON string via D-Bus to `xyz.openbmc_project.Inventory.Manager` at `/xyz/openbmc_project/sonic/rack_manager`, interface `com.sonic.RackManager`, method `SubmitAlert`.
  - `sonic_submit_telemetry.hpp`:
    - Similarly replace per-field parsing with JSON validation, require `Alarms`, and forward the full JSON to `SubmitTelemetry` on the same D-Bus interface.
- sonic-dbus-bridge:
  - Introduce `FieldType` and `FieldMapping` plus mapping tables in `field_mapping.hpp`:
    - `getTelemetryMappings()` maps JSON paths under `Alarms.*` to fields in `RSCM_TELEMETRY|alarms`.
    - `getAlertMappings()` maps JSON paths under `redfish_alert_data.*` to fields in `RSCM_ALERT|<AlertType>` hashes.
  - Add `RackManagerReceiver` (`rack_manager_receiver.hpp/.cpp`):
    - Register D-Bus interface `com.sonic.RackManager` at `/xyz/openbmc_project/sonic/rack_manager`.
    - Implement `SubmitAlert(s json) -> b` and `SubmitTelemetry(s json) -> b` methods.
    - Parse JSON using jsoncpp, resolve dot-separated JSON paths, serialise values by type, and issue HSET calls into Redis STATE_DB (DB index 6).
  - Wire receiver into the bridge:
    - Include `rack_manager_receiver.hpp` in `bridge_app.hpp` and create `rackManagerReceiver_` member.
    - In `BridgeApp::initialize()`, construct and initialize the receiver, and register the rack manager object with the ObjectMapper when successful.
    - Add `src/rack_manager_receiver.cpp` to `meson.build` sources.

[mssonicbld]

/azp run

[azure-pipelines]

No pipelines are associated with this pull request.

[mssonicbld]

/azp run

[azure-pipelines]

No pipelines are associated with this pull request.

[roger-nexthop]

May be good to generalize this name so that it is clear that both alarm and telemetry data are contained

[mssonicbld]

/azp run

[azure-pipelines]

No pipelines are associated with this pull request.

[mssonicbld]

/azp run

[azure-pipelines]

No pipelines are associated with this pull request.

[roger-nexthop]

InletTempDeviation would match JSON

[roger-nexthop]

Should we reject an empty JSON?