Add OEM Interface in bmcweb

Add OEM Interface in bmcweb

[Ratan Gupta]

[-- Attachment #1: Type: text/plain, Size: 1336 bytes --]

Hi All,

The purpose of this mail is to define the process/steps for adding the 
OEM interfaces.

Our first step would be to get the buying from the openbmc community for 
OEM interfaces/OEM properties.

If as a community we are on the same page then we can push these 
enhancements to DMTF.

eg: Redfish Dump service proposal review which is going on in the 
openBMC community.

If the enhancements are specific to OEM then we can add the OEM 
interfaces as following.

1) Introduce a compile time flag in the bmcweb

2) Put all the OEM specific interface functionalities in the new files.

3) Include the new files under the compile time flag as majority of the 
code in bmcweb written in header file.

If the OEM interfaces is redfish like interface then we need to do the 
following steps

     a) Implement the oem service root(eg: ibm/v1)

     b) Create the schema files

     c) Implement the metadata(ibm/v1/$metadata)

     d) Make the changes in the bb file so it installs the OEM schema 
files at the correct location.

     e) Storing the OEM schema files shall be some enterprise specific path.

Reference code is at the below location.(metadata implementation is WIP)
https://gerrit.openbmc-project.xyz/c/openbmc/bmcweb/+/27982 
<https://gerrit.openbmc-project.xyz/c/openbmc/bmcweb/+/27982/2>

Ratan







[-- Attachment #2: Type: text/html, Size: 2632 bytes --]

Re: Add OEM Interface in bmcweb

[Patrick Williams]

[-- Attachment #1: Type: text/plain, Size: 647 bytes --]

On Mon, Jan 20, 2020 at 12:43:57PM +0530, Ratan Gupta wrote:
> 1) Introduce a compile time flag in the bmcweb

> 2) Put all the OEM specific interface functionalities in the new files.
> 
> 3) Include the new files under the compile time flag as majority of the code
> in bmcweb written in header file.
> 

Do we want OEM commands to be in bmcweb also?  Or more of a plugin
nature like the IPMI implementation?

It seems to me that there will be OEM commands that are not open source
either due to NDAs on certain hardware or secret sauce in data center
management software that various cloud vendors have.

-- 
Patrick Williams

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: Add OEM Interface in bmcweb

[Ratan Gupta]

[-- Attachment #1: Type: text/plain, Size: 1270 bytes --]


On 22/01/20 3:28 AM, Patrick Williams wrote:
> On Mon, Jan 20, 2020 at 12:43:57PM +0530, Ratan Gupta wrote:
>> 1) Introduce a compile time flag in the bmcweb
>> 2) Put all the OEM specific interface functionalities in the new files.
>>
>> 3) Include the new files under the compile time flag as majority of the code
>> in bmcweb written in header file.
>>
> Do we want OEM commands to be in bmcweb also?
Yes Redfish has a support for the same, However we want to minimize the 
need as much as possible by
1) Put across your need in the community and find out if this is a 
common requirement
2) If it is a common requirement across the openBMC community then 
propose it in the DMTF.
>   Or more of a plugin
> nature like the IPMI implementation?
We tried the same earlier in the community call and discussed that we 
should avoid it for the following reason.

  * People will start using the Oem here and there and the community
    will never know the requirement which can be standardized.


> It seems to me that there will be OEM commands that are not open source
> either due to NDAs on certain hardware or secret sauce in data center
> management software that various cloud vendors have.
Yes certain OEM cmds would be there which can not be standardized.
Ratan

[-- Attachment #2: Type: text/html, Size: 2688 bytes --]

Re: Add OEM Interface in bmcweb

[Richard Hanley]

[-- Attachment #1: Type: text/plain, Size: 2953 bytes --]

This is an area where I think we need to make some clearer distinctions on
what OEM means.  By that I mean there are two main use cases of OEM fields:

1) OEM fields that are directly part of the phosphor reference
implementation used in all of OpenBMC
2) OEM fields that are used for individual projects or corporations.

Minimizing number 1 is a really good goal, because we should be able to use
Redfish by default in OpenBMC without needing any OEM fields. Moreover any
fields that are generally needed in OpenBMC should be adopted by DMTF.

However, that second use case is really really different.   For example, we
have some incredibly specific requirements about providing a detailed
physical model of the machine to the rest of the datacenter.  When we
approached DMTF about this, their recommendation was to graft this metadata
into the assemblies (which is a very reasonable way to accomplish that).
As it stands right now, I don't have a really clear idea on how to
sustainably add that into bmcweb.  This problem gets more thorny if a
company wants to add Redfish support for a custom ASIC.

This is a balancing act that I think needs to be addressed in some
fashion.  One possible way to square this circle is to work with DMTF on
creating Redfish profiles.  That way we can have a core library that allows
for the easy pluggability and ad-hoc support, but then have standard
profiles that clients can design around.  I know that DMTF is very
interested in creating profiles, and this might be a use case that helps
drive that.

Regards,
Richard

On Thu, Feb 13, 2020 at 12:36 AM Ratan Gupta <ratagupt@linux.vnet.ibm.com>
wrote:

>
> On 22/01/20 3:28 AM, Patrick Williams wrote:
>
> On Mon, Jan 20, 2020 at 12:43:57PM +0530, Ratan Gupta wrote:
>
> 1) Introduce a compile time flag in the bmcweb
>
> 2) Put all the OEM specific interface functionalities in the new files.
>
> 3) Include the new files under the compile time flag as majority of the code
> in bmcweb written in header file.
>
>
> Do we want OEM commands to be in bmcweb also?
>
> Yes Redfish has a support for the same, However we want to minimize the
> need as much as possible by
> 1) Put across your need in the community and find out if this is a common
> requirement
> 2) If it is a common requirement across the openBMC community then propose
> it in the DMTF.
>
>  Or more of a plugin
> nature like the IPMI implementation?
>
> We tried the same earlier in the community call and discussed that we
> should avoid it for the following reason.
>
>    - People will start using the Oem here and there and the community
>    will never know the requirement which can be standardized.
>
>
> It seems to me that there will be OEM commands that are not open source
> either due to NDAs on certain hardware or secret sauce in data center
> management software that various cloud vendors have.
>
> Yes certain OEM cmds would be there which can not be standardized.
>
> Ratan
>

[-- Attachment #2: Type: text/html, Size: 4146 bytes --]