Redfish OpenBMC OEM
James Feist
james.feist at linux.intel.com
Thu Nov 21 04:47:11 AEDT 2019
On 11/20/19 7:57 AM, Joseph Reynolds wrote:
> On 11/19/19 1:04 PM, James Feist wrote:
>> On 11/19/19 10:03 AM, Joseph Reynolds wrote:
>>> On 11/19/19 10:23 AM, Gunnar Mills wrote:
>>>> Hi All,
>>>>
>>>> The process seems a little light for adding OpenBMC OEM Redfish
>>>> properties and schemas. Can we establish a little more stringent
>>>> process for adding these? Can we try to upstream these to the
>>>> Redfish standard first before they are added as OpenBMC OEM? Do we
>>>> need a design template or someway to collaborate before the OpenBMC
>>>> OEM schema or properties are added? Are we okay if pretty
>>>> architectural-specific or company-specific properties and schemas
>>>> are under the "OpenBMC" OEM namespace?
>>>>
>>>
>>> I suggest getting started with a survey of what the project has.
>>> Given that we have Redfish Oem.OpenBMC Properties, we should document
>>> them (suggest: docs/designs/Redfish-Oem-Resources.md and using a
>>> format similar to the Redfish spec). Doing so will help:
>>> - users know what to expect from the interfaces,
>>> - developers to understand the interface, and
>>> - the OpenBMC community to help move these fields into the Redfish spec.
>>>
>>> The proposed Redfish-Oem-Resources document would serve as a good
>>> focal point for collaboration within OpenBMC as to how we want to
>>> extend the Redfish spec.
>>
>> There is already schema checked in for everything Oem, refer
>> https://github.com/openbmc/bmcweb/tree/master/static/redfish/v1/schema
>>
>> OemAccountService
>> OemComputerSystem
>> OemManager
>>
>> Redfish uses schema to define these things, I'd rather continue using
>> the schema files instead of creating a new document that could become
>> out of date quickly.
>>
>
> James, thanks for that reference. You're way ahead of me.
>
> Would the bmcweb/static/redfish/v1/schema directory be an adequate focal
> point for collaboration? I think so:
> - Is it complete? Does it list all of the OpenBMC Oem resources? Or
> (contrarywise) does OpenBMC have Oem resources which are not represented
> in that collection?
To the best of my knowledge it is complete, as we require the validator
to be ran, and the validator would not pass without these schema.
> - It seems like it is easy to search.
> - It would be easy to identify proposed changes to files in this
> directory during a gerrit review.
>
> Gunnar, does that begin to address your concern?
>
> - Joseph
>
>>
>>>
>>> Reference:
>>> Oem Resources are described in the Redfish spec (DSP0266) in the Data
>>> model chapter under multiple section such as OEM Resources and
>>> Resource extensibility.
>>>
>>> It seems to me that "OpenBMC" should be used for common elements and
>>> "company name" (such as "OpenPower" or "IBM") used when appropriate.
>>> Once again, the OpenBMC community needs to have a focus in this area
>>> to sort this out. IMHO, having a document like
>>> Redfish-Oem-Resources.md would help.
>>>
>>>
>>>> I think a majority of the OEM properties in the "OpenBMC" OEM
>>>> currently are things Redfish would take. I would like to see us
>>>> engage Redfish first.
>>>
>>> Agreed. I understand this statement to mean that we should try to
>>> upstream new Resources into the Redfish spec first, before we accept
>>> them as Oem.OpenBMC resources. Also, we should try to upstream the
>>> existing OpenBMC resources into Redfish.
>>>
>>> I think having a Redfish-Oem-Resources document would help provide
>>> focus to that effort.
>>>
>>> - Joseph
>>>
>>>>
>>>> Some examples:
>>>> FirmwareProvisioningStatus,
>>>> https://github.com/openbmc/bmcweb/commit/a6349918ad2c88533c6d09bb876812375a19f2c4
>>>>
>>>>
>>>> FanZones,
>>>> https://github.com/openbmc/bmcweb/blob/a6349918ad2c88533c6d09bb876812375a19f2c4/static/redfish/v1/JsonSchemas/OemManager/index.json#L248
>>>>
>>>>
>>>> Thanks,
>>>> Gunnar
>>>>
>>>
>
More information about the openbmc
mailing list