Redfish: Supporting deprecated properties

Joseph Reynolds jrey at linux.ibm.com
Tue Oct 6 11:52:26 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 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!
>>
>> Clients can use the schema version to determine which properties are
>> available. If needed companies in a fork could maintain backward
>> compatibility for longer.
> In practice, many clients don't check the schema at all.  I really
> wish Redfish had a way for a client to say "I support X version of the
> schema, give me the things compatible with that", but I'm not aware of
> anything like that.
>
>> Thanks,
>> Gunnar



More information about the openbmc mailing list