Redfish: Supporting deprecated properties
Gunnar Mills
gmills at linux.vnet.ibm.com
Tue Oct 6 07:34:48 AEDT 2020
Felt this needed some broader discussion. Although Redfish tries to
avoid, it does deprecate properties. In the future, Redfish plans to
deprecate whole schemas. One of these deprecated properties was the
IndicatorLED property, replaced by the LocationIndicatorActive property.
More information on this can be found at (Slide 11):
http://www.dmtf.org/sites/default/files/Redfish_Release_2020.3_Overview.pdf
On https://gerrit.openbmc-project.xyz/c/openbmc/bmcweb/+/36886, it was
proposed supporting both the deprecated and new property for some time.
This would introduce a new Redfish Validator warning about implementing
a deprecated property. We have other warnings today so maybe not a big deal.
How long do we need to support both properties?
Based on releases? 6 months? That feels too long. Are our releases used
broadly enough and release process mature enough?
If it is not a replacement and just deprecating a property, can we just
drop the deprecated property immediately when switching to a new schema
version that deprecates?
Do we need to do the same when a schema is deprecated? This matters
because Redfish is targeting 2020.4 for new Power and Thermal Subsystem
Schemas. Redfish plans to deprecate the old Power and Thermal Schemas
and release new schemas.
I think it is reasonable we support both IndicatorLED and
LocationIndicatorActive for some time, I'll throw out 2 months. Our
Redfish implementation is young and I am not sure it is worth the
developmental and support costs, at least at this time, to maintain
deprecated properties and schemas for long.
Clients can use the schema version to determine which properties are
available. If needed companies in a fork could maintain backward
compatibility for longer.
Thanks,
Gunnar
More information about the openbmc
mailing list