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