| e7bcf475 | 17-Nov-2024 |
Jayanth Othayoth <ojayanth@gmail.com> |
json utility: fixed core dump during sensor load
bmcweb replaces underscores with spaces in sensor names for better
readability. The existing objectKeyCmp function did not handle this
case, leading
json utility: fixed core dump during sensor load
bmcweb replaces underscores with spaces in sensor names for better
readability. The existing objectKeyCmp function did not handle this
case, leading to core dumps in the sensor load path.
Error details are provided below.
```
bmcwebd[1368]: [DEBUG sensors.hpp:507] Added sensor P0_NS_VR_FAN_2
bmcwebd[1368]: terminate called after throwing an instance of
'boost::detail::with_throw_location<boost::system::system_error>'
bmcwebd[1368]: what(): leftover [boost.url.grammar:4]
```
Implemented a new algorithm that alphabetically sorts non-URL keys
and retains the existing logic for URL-type keys.
Tested: Updated and verified the test cases.
Change-Id: I39c3f7cc54dec5e7cf9658977e1078acb827afb2
Signed-off-by: Jayanth Othayoth <ojayanth@gmail.com>
Signed-off-by: Ed Tanous <etanous@nvidia.com>
show more ...
|
| 340d74c8 | 12-Oct-2024 |
Myung Bae <myungbae@us.ibm.com> |
Handling of OutOfRange in ReadJson
Currently readJsonPatch returns `PropertValueNotInList` in case when an
input integer is out of range. This change is to return
`PropertyValueOutOfRange` for the
Handling of OutOfRange in ReadJson
Currently readJsonPatch returns `PropertValueNotInList` in case when an
input integer is out of range. This change is to return
`PropertyValueOutOfRange` for the case out-of-range integer input.
Tested:
- Verify PATCH with an out-of-value integer. e.g.
```
$ curl -k -X PATCH https://${bmc}/redfish/v1/EventService/ -H "Content-Type: application/json" -d '{ "DeliveryRetryIntervalSeconds" : 4294967296}'
```
Before the change, its `MessageId` is `PropertyValueNotInList`.
```
"Message": "The value '4294967296' for the property DeliveryRetryIntervalSeconds is not in the list of acceptable values.",
"MessageId": "Base.1.19.0.PropertyValueNotInList",
"MessageSeverity": "Warning",
"Resolution": "Choose a value from the enumeration list that the implementation can support and resubmit the request if the operation failed."
```
After the change, its `MessageId` will be `PropertyValueOutOfRange`.
```
"Message": "The value '4294967296' for the property DeliveryRetryIntervalSeconds is not in the supported range of acceptable values.",
"MessageId": "Base.1.19.0.PropertyValueOutOfRange",
"MessageSeverity": "Warning",
"Resolution": "Correct the value for the property in the request body and resubmit the request if the operation failed."
```
- Redfish Service Validator passes
Change-Id: I0d0c5ecbc9f416b68fa7c0e81a0ea896ec2e50af
Signed-off-by: Myung Bae <myungbae@us.ibm.com>
show more ...
|
| 6fe8751c | 20-Jul-2023 |
George Liu <liuxiwei@inspur.com> |
Implement TemperatureReadingsCelsius property for ThermalMetrics
The ThermalMetrics schema[1] provides for efficient thermal metric
gathering for thermal sensors. The schema allows retrieving just t
Implement TemperatureReadingsCelsius property for ThermalMetrics
The ThermalMetrics schema[1] provides for efficient thermal metric
gathering for thermal sensors. The schema allows retrieving just the
thermal metrics with one Redfish URI. This prevents the additional work
required when returning all the sensor data, or multiple Redfish URI
calls to retrieve the properties for all of the thermal sensors.
This commit implements the TemperatureReadingsCelsius property of
ThermalMetrics[1]. ThermalMetrics is a property of ThermalSubsystem[2].
TemperatureReadingsCelsius is a SensorArrayExcerpt[3].
[1] https://redfish.dmtf.org/schemas/v1/ThermalMetrics.v1_0_1.json
[2] https://redfish.dmtf.org/schemas/v1/ThermalSubsystem.v1_3_2.json
[3] http://redfish.dmtf.org/schemas/v1/Sensor.v1_9_0.json#/definitions/SensorArrayExcerpt
The temperature sensors are found by finding 'all_sensors' endpoints for
specific chassis of D-Bus service
/xyz/openbmc_project/sensors/temperature. An entry of SensorArrayExcerpt
is built for each temperature sensor retrieved.
Implementation Notes:
- Common function sensor_utils::objectPropertiesToJson() is used to
fill in sensor excerpt properties. Currently the only excerpt
ChassisSubNode is ThermalMetrics. However there are others excerpts
defined by Redfish. Right now mostly this is just skipping things,
but I'm expecting when other sensor excerpts are implemented that
some of the other properties may be added for excerpts as well. I'm
expecting the combination of the chassisSubNode and the sensorType
will be used to determine which properties are included for a
particular call to build a sensor Json representation.
- New sensor_utils::objectExcerptToJson() function created. This wraps
sensor_utils::objectPropertiesToJson() and builds DataSourceUri for a
sensor excerpt.
- New sensor_utils::getAllSensorObjects() function created. This builds
list of 'all_sensors' association endpoints for specified D-Bus path
with specified D-Bus interfaces. Callback function is called with
list for handling sensors.
Tested:
1. Redfish Service Validator passed.
2. doGet method:
```
curl -k -H "X-Auth-Token: ${token}" -X GET https://${bmc}/redfish/v1/Chassis/chassis/ThermalSubsystem/ThermalMetrics
{
"@odata.id": "/redfish/v1/Chassis/chassis/ThermalSubsystem/ThermalMetrics",
"@odata.type": "#ThermalMetrics.v1_0_1.ThermalMetrics",
"Id": "ThermalMetrics",
"Name": "Thermal Metrics",
"TemperatureReadingsCelsius": [
{
"DataSourceUri": "/redfish/v1/Chassis/chassis/Sensors/temperature_ps0_temp0",
"Reading": -131072000.0
},
{
"DataSourceUri": "/redfish/v1/Chassis/chassis/Sensors/temperature_ps0_temp1",
"Reading": -131072000.0
},
{
"DataSourceUri": "/redfish/v1/Chassis/chassis/Sensors/temperature_ps0_temp2",
"Reading": -131072000.0
},
{
"DataSourceUri": "/redfish/v1/Chassis/chassis/Sensors/temperature_ps1_temp0",
"Reading": -131072000.0
},
{
"DataSourceUri": "/redfish/v1/Chassis/chassis/Sensors/temperature_ps1_temp1",
"Reading": -131072000.0
},
{
"DataSourceUri": "/redfish/v1/Chassis/chassis/Sensors/temperature_ps1_temp2",
"Reading": -131072000.0
}
],
"TemperatureReadingsCelsius@odata.count": 6
}
```
3. Verification of DataSourceUri:
```
curl -k -H "X-Auth-Token: ${token}" -X GET https://${bmc}/redfish/v1/Chassis/chassis/Sensors/temperature_ps1_temp0
{
"@odata.id": "/redfish/v1/Chassis/chassis/Sensors/temperature_ps1_temp0",
"@odata.type": "#Sensor.v1_2_0.Sensor",
"Id": "temperature_ps1_temp0",
"Name": "ps1 temp0",
"Reading": -131072000.0,
"ReadingType": "Temperature",
"ReadingUnits": "Cel",
"Status": {
"Health": "OK",
"State": "Enabled"
}
}
```
4. A bad chassis ID:
```
curl -k -H "X-Auth-Token: ${token}" -X GET https://${bmc}/redfish/v1/Chassis/chassisBAD/ThermalSubsystem/ThermalMetrics
{
"error": {
"@Message.ExtendedInfo": [
{
"@odata.type": "#Message.v1_1_1.Message",
"Message": "The requested resource of type Chassis named 'chassisBAD' was not found.",
"MessageArgs": [
"Chassis",
"chassisBAD"
],
"MessageId": "Base.1.18.1.ResourceNotFound",
"MessageSeverity": "Critical",
"Resolution": "Provide a valid resource identifier and resubmit the request."
}
],
"code": "Base.1.18.1.ResourceNotFound",
"message": "The requested resource of type Chassis named 'chassisBAD' was not found."
}
}
```
Signed-off-by: George Liu <liuxiwei@ieisystem.com>
Change-Id: I6e4ed1f281fd5371c978983b6cc5666badd3752c
Signed-off-by: Janet Adkins <janeta@us.ibm.com>
show more ...
|
| b5190062 | 10-Jul-2024 |
Hieu Huynh <hieuh@os.amperecomputing.com> |
Support ProductionDate report
DSP0268 Redfish Data Model Specification provides ProductionDate
property for various schema. phosphor-dbus-interface [1] also
supports BuildDate property which we can
Support ProductionDate report
DSP0268 Redfish Data Model Specification provides ProductionDate
property for various schema. phosphor-dbus-interface [1] also
supports BuildDate property which we can map from FRU data, like
`Board Manufacturer Date`.
This adds code to support which gets the date from BuildDate
property and report via Redfish.
[1] https://github.com/openbmc/phosphor-dbus-interfaces/blob/master/yaml/xyz/openbmc_project/Inventory/Decorator/Asset.interface.yaml#L16
Tested: Redfish Validator passes
Signed-off-by: Hieu Huynh <hieuh@os.amperecomputing.com>
Change-Id: Ie4ae564fa00218e7896f04ec61941fa92b23b912
show more ...
|
| 352e3b78 | 04-Oct-2024 |
Hieu Huynh <hieuh@os.amperecomputing.com> |
dateStringToEpoch: add the additional format
This adds the additional format for ISO 8601, such as YYYYMMDD or
YYYYMMDDThhmmssZ.
Tested:
Test case 1:
The input ISO 8601 timestamp: 20230531T000000Z
dateStringToEpoch: add the additional format
This adds the additional format for ISO 8601, such as YYYYMMDD or
YYYYMMDDThhmmssZ.
Tested:
Test case 1:
The input ISO 8601 timestamp: 20230531T000000Z
The output Epoch timestamp: 1685491200000000
Test case 2:
The input ISO 8601 timestamp: 20230531
The output Epoch timestamp: 1685491200000000
Signed-off-by: Hieu Huynh <hieuh@os.amperecomputing.com>
Change-Id: I23080a466b2edeecb5d8a4fb7ec0b00739454056
show more ...
|
| 4e196b9a | 27-Sep-2024 |
Ed Tanous <etanous@nvidia.com> |
json utility: Update sort algorithms
Modified sort utility to be able to sort on a specified key.
New utility function sortJsonArrayByKey() added.
Note:
- Function odataObjectCmp() renamed to obje
json utility: Update sort algorithms
Modified sort utility to be able to sort on a specified key.
New utility function sortJsonArrayByKey() added.
Note:
- Function odataObjectCmp() renamed to objectKeyCmp()
- New function odataObjectCmp() created which calls objectKeyCmp() with
@odata.id key specified.
- Comments for odataObjectCmp() didn't match behavior for object
without key. These objects are sorted as less than objects with the
key.
- sortJSONResponse() modified to use the new sortJsonArrayByKey().
Tested:
- Added new unit tests. These tests are in addition to the existing
tests. So they focus on testing comparing by different keys.
The existing tests already cover the different permutations of the
basic comparisons.
- Redfish Service validator passes
Change-Id: I949b7cb868c59a8eeda3798e6a82a1572bbc5792
Signed-off-by: Ed Tanous <etanous@nvidia.com>
Signed-off-by: Janet Adkins <janeta@us.ibm.com>
show more ...
|
| 25b54dba | 17-Apr-2024 |
Ed Tanous <ed@tanous.net> |
Bring consistency to config options
The configuration options that exist in bmcweb are an amalgimation of
CROW options, CMAKE options using #define, pre-bmcweb ifdef mechanisms
and meson options usi
Bring consistency to config options
The configuration options that exist in bmcweb are an amalgimation of
CROW options, CMAKE options using #define, pre-bmcweb ifdef mechanisms
and meson options using a config file. This history has led to a lot of
different ways to configure code in the codebase itself, which has led
to problems, and issues in consistency.
ifdef options do no compile time checking of code not within the branch.
This is good when you have optional dependencies, but not great when
you're trying to ensure both options compile.
This commit moves all internal configuration options to:
1. A namespace called bmcweb
2. A naming scheme matching the meson option. hyphens are replaced with
underscores, and the option is uppercased. This consistent transform
allows matching up option keys with their code counterparts, without
naming changes.
3. All options are bool true = enabled, and any options with _ENABLED or
_DISABLED postfixes have those postfixes removed. (note, there are
still some options with disable in the name, those are left as-is)
4. All options are now constexpr booleans, without an explicit compare.
To accomplish this, unfortunately an option list in config/meson.build
is required, given that meson doesn't provide a way to dump all options,
as is a manual entry in bmcweb_config.h.in, in addition to the
meson_options. This obsoletes the map in the main meson.build, which
helps some of the complexity.
Now that we've done this, we have some rules that will be documented.
1. Runtime behavior changes should be added as a constexpr bool to
bmcweb_config.h
2. Options that require optionally pulling in a dependency shall use an
ifdef, defined in the primary meson.build. (note, there are no
options that currently meet this class, but it's included for
completeness.)
Note, that this consolidation means that at configure time, all options
are printed. This is a good thing and allows direct comparison of
configs in log files.
Tested: Code compiles
Server boots, and shows options configured in the default build. (HTTPS,
log level, etc)
Change-Id: I94e79a56bcdc01755036e4e7278c7e69e25809ce
Signed-off-by: Ed Tanous <ed@tanous.net>
show more ...
|
| 8099c517 | 01-Nov-2023 |
Ed Tanous <edtanous@google.com> |
Allow parsing null or value classes
In Redfish schema, just about all values can be a type (string,
EDM.Numeric, etc) or null. Most APIs don't allow explicitly setting
null, but there are a few cas
Allow parsing null or value classes
In Redfish schema, just about all values can be a type (string,
EDM.Numeric, etc) or null. Most APIs don't allow explicitly setting
null, but there are a few cases where it is useful, namely in lists,
where an an empty object {} keeps the value the same, and null deletes
the value from the list.
Previously we handled this by unpacking as nlohmann::json, but this
allowed things like
[1.0, {}] to pass the check for an array of string values. We'd
ideally like to reject the 1.0 at the first stage, as well as reduce
the number of tiered readJson calls that we make.
This commit introducess support for unpacking std::variant types, that
allows unpacking a known type, or explicitly allowing null, by unpacking
std::nullptr_t.
Tested: Unit tests pass.
Change-Id: Ic7451877c824ac743faf1951cc2b5d9f8df8019c
Signed-off-by: Ed Tanous <edtanous@google.com>
show more ...
|
| d02aad39 | 13-Feb-2024 |
Ed Tanous <ed@tanous.net> |
Create Redfish specific setProperty call
There are currently 78 sdbusplus::asio::setProperty calls in
redfish-core. The error handler for nearly all of them looks something
like:
```
if (ec)
{
Create Redfish specific setProperty call
There are currently 78 sdbusplus::asio::setProperty calls in
redfish-core. The error handler for nearly all of them looks something
like:
```
if (ec)
{
const sd_bus_error* dbusError = msg.get_error();
if ((dbusError != nullptr) &&
(dbusError->name ==
std::string_view(
"xyz.openbmc_project.Common.Error.InvalidArgument")))
{
BMCWEB_LOG_WARNING("DBUS response error: {}", ec);
messages::propertyValueIncorrect(asyncResp->res, "<PropertyName>", <PropertyValue>);
return;
}
messages::internalError(asyncResp->res);
return;
}
messages::success(asyncResp->res);
```
In some cases there are more errors handled that translate to more error
messages, but the vast majority only handle InvalidArgument. Many of
these, like the ones in account_service.hpp, do the error handling in a
lambda, which causes readability problems. This commit starts to make
things more consistent, and easier for trivial property sets.
This commit invents a setDbusProperty method in the redfish namespace
that tries to handle all DBus errors in a consistent manner. Looking
for input on whether this will work before changing over the other 73
calls. Overall this is less code, fewer inline lambdas, and defaults
that should work for MOST use cases of calling an OpenBMC daemon, and
fall back to more generic errors when calling a "normal" dbus daemon.
As part of this, I've ported over several examples. Some things that
might be up in the air:
1. Do we always return 204 no_content on property sets? Today there's a
mix of 200, with a Base::Success message, and 204, with an empty body.
2. Do all DBus response codes map to the same error? A majority are
covered by xyz.openbmc_project.Common.Error.InvalidArgument, but there
are likely differences. If we allow any daemon to return any return
code, does that cause compatibility problems later?
Tested:
```
curl -k --user "root:0penBmc" -H "Content-Type: application/json" -X PATCH -d '{"HostName":"openbmc@#"}' https://192.168.7.2/redfish/v1/Managers/bmc/EthernetInterfaces/eth0
```
Returns the appropriate error in the response
Base.1.16.0.PropertyValueIncorrect
Change-Id: If033a1112ba516792c9386c997d090c8f9094f3a
Signed-off-by: Ed Tanous <ed@tanous.net>
show more ...
|