Redfish: Supporting deprecated properties

Joseph Reynolds jrey at linux.ibm.com
Tue Oct 6 11:52:06 AEDT 2020



On 10/5/20 4:35 PM, Ed Tanous wrote:
> On Mon, Oct 5, 2020 at 1:34 PM Gunnar Mills <gmills at linux.vnet.ibm.com> wrote:
>> 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.
...snip...
>
> In this specific case, what if we did this:
> Now;  Upstream backward compatible LocationIndicatorActive property to
> bmcweb.  Upstream changes to OCP schema to also deprecate
> IndicatorLed.  Time starts counting once both patches have been
> accepted into their respective mainline branches.
> N+1 release;  Implement returning a deprecation warning to the user
> attempting to use the IndicatorLED PATCH API.
> N+2 release; Remove the IndicatorLED property from GET requests, but
> continue to accept the property for PATCH requests (we've done this in
> other cases).
> N+3 release; Disallow PATCH to that property entirely, and continue
> with new implementation.  Ideally hold the deprecation warning, but
> use judgement about technical debt.
>
> ?????
>
> Profit!

Can we discuss this without referencing South Park, season 2, episode 
17, please?

- Joseph



More information about the openbmc mailing list