Redfish OpenBMC OEM

Redfish OpenBMC OEM

[Gunnar Mills]

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 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.

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

Re: Redfish OpenBMC OEM

[Joseph Reynolds]

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.

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
>

Re: Redfish OpenBMC OEM

[James Feist]

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.


> 
> 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
>>
> 

Re: Redfish OpenBMC OEM

[Joseph Reynolds]

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?
  - 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
>>>
>>

Re: Redfish OpenBMC OEM

[James Feist]

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
>>>>
>>>
> 

Re: Redfish OpenBMC OEM

[Gunnar Mills]

On 11/20/2019 11:47 AM, James Feist wrote:
> 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:
>>>>>
>>>>> 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?
>>>>>
>>
>> Gunnar, does that begin to address your concern?

I am most concerned with us adding these OpenBMC OEM schemas and 
properties without first engaging the Redfish Group.

James, Joseph, and others would you support having a guideline, stating 
before adding an OEM schema or property, please first engage the Redfish 
Group? Things Redfish is not interested in taking are an obvious 
exception. I am also fine with things that are in the process of being 
up-streamed, being added as OEM temporarily.


Thanks,
Gunnar

Re: Redfish OpenBMC OEM

[James Feist]

On 11/20/19 2:45 PM, Gunnar Mills wrote:
> 
> On 11/20/2019 11:47 AM, James Feist wrote:
>> 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:
>>>>>>
>>>>>> 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?
>>>>>>
>>>
>>> Gunnar, does that begin to address your concern?
> 
> I am most concerned with us adding these OpenBMC OEM schemas and 
> properties without first engaging the Redfish Group.
> 
> James, Joseph, and others would you support having a guideline, stating 
> before adding an OEM schema or property, please first engage the Redfish 
> Group? Things Redfish is not interested in taking are an obvious 
> exception. I am also fine with things that are in the process of being 
> up-streamed, being added as OEM temporarily.

What redfish group are you mentioning?

> 
> 
> Thanks,
> Gunnar
> 

Re: Redfish OpenBMC OEM

[Gunnar Mills]

On 11/20/2019 5:50 PM, James Feist wrote:
> On 11/20/19 2:45 PM, Gunnar Mills wrote:
>>
>> On 11/20/2019 11:47 AM, James Feist wrote:
>>> 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:
>>>>>>>
>>>>>>> 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?
>>>>>>>
>>
>> James, Joseph, and others would you support having a guideline, 
>> stating before adding an OEM schema or property, please first engage 
>> the Redfish Group? Things Redfish is not interested in taking are an 
>> obvious exception. I am also fine with things that are in the process 
>> of being up-streamed, being added as OEM temporarily.
>
> What redfish group are you mentioning?
>

DMTF’s Redfish

They have an open forum here,  to ask questions and request features: 
https://redfishforum.com/

To get access to the Redfish code repository and meetings
1) Your company must be a Redfish Supporter or Promoter, a lot of 
companies working on OpenBMC are
2) Join the DMTF, www.dmtf.org/join
3) Join the "Redfish Forum" working group, 
https://members.dmtf.org/apps/org/workgroup/portal/
4) Send an email asking for access to the Redfish code repository

I was thinking either of these would establish "engaging Redfish".

Thanks,
Gunnar

Re: Redfish OpenBMC OEM

[James Feist]

On 11/21/19 7:39 AM, Gunnar Mills wrote:
> 
> On 11/20/2019 5:50 PM, James Feist wrote:
>> On 11/20/19 2:45 PM, Gunnar Mills wrote:
>>>
>>> On 11/20/2019 11:47 AM, James Feist wrote:
>>>> 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:
>>>>>>>>
>>>>>>>> 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?
>>>>>>>>
>>>
>>> James, Joseph, and others would you support having a guideline, 
>>> stating before adding an OEM schema or property, please first engage 
>>> the Redfish Group? Things Redfish is not interested in taking are an 
>>> obvious exception. I am also fine with things that are in the process 
>>> of being up-streamed, being added as OEM temporarily.
>>
>> What redfish group are you mentioning?
>>
> 
> DMTF’s Redfish
> 
> They have an open forum here,  to ask questions and request features: 
> https://redfishforum.com/
> 
> To get access to the Redfish code repository and meetings
> 1) Your company must be a Redfish Supporter or Promoter, a lot of 
> companies working on OpenBMC are
> 2) Join the DMTF, www.dmtf.org/join
> 3) Join the "Redfish Forum" working group, 
> https://members.dmtf.org/apps/org/workgroup/portal/
> 4) Send an email asking for access to the Redfish code repository
> 
> I was thinking either of these would establish "engaging Redfish".

I'd be fine with adding this to the docs/readme, however as your company 
has to be a supporter, it should probably be a weak requirement.

> 
> Thanks,
> Gunnar

Re: Redfish OpenBMC OEM

[Gunnar Mills]

On 11/21/2019 12:16 PM, James Feist wrote:
> On 11/21/19 7:39 AM, Gunnar Mills wrote:
>>
>> On 11/20/2019 5:50 PM, James Feist wrote:
>>> On 11/20/19 2:45 PM, Gunnar Mills wrote:
>>>>>>>> On 11/19/19 10:23 AM, Gunnar Mills wrote:
>>>>>>>>>
>>>>>>>>> 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?
>>>>>>>>>
>>>>
>>>> James, Joseph, and others would you support having a guideline, 
>>>> stating before adding an OEM schema or property, please first 
>>>> engage the Redfish Group? Things Redfish is not interested in 
>>>> taking are an obvious exception. I am also fine with things that 
>>>> are in the process of being up-streamed, being added as OEM 
>>>> temporarily.
>>>
>>> What redfish group are you mentioning?
>>>
>>
>> DMTF’s Redfish
>>
>> They have an open forum here,  to ask questions and request features: 
>> https://redfishforum.com/
>>
>> To get access to the Redfish code repository and meetings
>> 1) Your company must be a Redfish Supporter or Promoter, a lot of 
>> companies working on OpenBMC are
>> 2) Join the DMTF, www.dmtf.org/join
>> 3) Join the "Redfish Forum" working group, 
>> https://members.dmtf.org/apps/org/workgroup/portal/
>> 4) Send an email asking for access to the Redfish code repository
>>
>> I was thinking either of these would establish "engaging Redfish".
>
> I'd be fine with adding this to the docs/readme, however as your 
> company has to be a supporter, it should probably be a weak requirement.
>
Added to the DEVELOPING.md here 
https://gerrit.openbmc-project.xyz/c/openbmc/bmcweb/+/27480/

The Redfish Specification Forum, https://redfishforum.com/  is public. 
Anyone can request features there.

Thanks,
Gunnar

Re: Redfish OpenBMC OEM - password not accepted

[Joseph Reynolds]

On 11/21/19 1:22 PM, Gunnar Mills wrote:
>
> On 11/21/2019 12:16 PM, James Feist wrote:
>> On 11/21/19 7:39 AM, Gunnar Mills wrote:
>>>
>>> On 11/20/2019 5:50 PM, James Feist wrote:
>>>> On 11/20/19 2:45 PM, Gunnar Mills wrote:
>>>>>>>>> On 11/19/19 10:23 AM, Gunnar Mills wrote:
>>>>>>>>>>
>>>>>>>>>> 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?
>>>>>>>>>>
>>>>>
>>>>> James, Joseph, and others would you support having a guideline, 
>>>>> stating before adding an OEM schema or property, please first 
>>>>> engage the Redfish Group? Things Redfish is not interested in 
>>>>> taking are an obvious exception. I am also fine with things that 
>>>>> are in the process of being up-streamed, being added as OEM 
>>>>> temporarily.
>>>>
>>>> What redfish group are you mentioning?
>>>>
>>>
>>> DMTF’s Redfish
>>>
>>> They have an open forum here,  to ask questions and request 
>>> features: https://redfishforum.com/
>>>
>>> To get access to the Redfish code repository and meetings
>>> 1) Your company must be a Redfish Supporter or Promoter, a lot of 
>>> companies working on OpenBMC are
>>> 2) Join the DMTF, www.dmtf.org/join
>>> 3) Join the "Redfish Forum" working group, 
>>> https://members.dmtf.org/apps/org/workgroup/portal/
>>> 4) Send an email asking for access to the Redfish code repository
>>>
>>> I was thinking either of these would establish "engaging Redfish".
>>
>> I'd be fine with adding this to the docs/readme, however as your 
>> company has to be a supporter, it should probably be a weak requirement.
>>
> Added to the DEVELOPING.md here 
> https://gerrit.openbmc-project.xyz/c/openbmc/bmcweb/+/27480/

There is a vehicle to move this effort forward.  I created a [patch][] 
which defines a new Oem.OpenBMC property for a needed function.  Support 
for this function is already being discussed in a Redfish forum [thread][].

[patch]: https://gerrit.openbmc-project.xyz/c/openbmc/bmcweb/+/27503
[thread]: 
https://redfishforum.com/thread/246/message-send-patch-password-failure

So, the patch is exactly correct.  Please help me out.  It seems like I 
should try to create a new Redfish message.  Here are ideas for a 
straw-man draft for a new Redfish standard message
- Id: PropertyValueError
- Message: The value XYZ for the property ABC was not accepted.
- Resolution: Correct the value for the property in the request body and 
resubmit the request if the operation failed.  Additional information 
about the cause may be provided in the ExtendedInfo.

Then represent each possible cause as an individual 
PropertyValueError@.MessageExtendedInfo message:
  - "The value XYZ  for the property ABC does not comply with the 
regular expression."
  - "The value for the Password property was not accepted.  The reason 
is: %1"  -- I've omitted the password value itself from the message.  
This was done to try to keep the value confidential.  Is that warranted, 
or can we have a generic message (as on the next item below)?  A use 
case for this is messages from PAM like "BAD PASSWORD: it is way too short".
- "The value %1 for the property %2 was not accepted.  The reason is: %3"

Each of the ExtendedInfo messages would also need a formal spec.

Does that sound right?

- Joseph

>
> The Redfish Specification Forum, https://redfishforum.com/  is public. 
> Anyone can request features there.
>
> Thanks,
> Gunnar
>
>

Re: Redfish OpenBMC OEM

[Gunnar Mills]

On 11/21/2019 1:22 PM, Gunnar Mills wrote:
>
> On 11/21/2019 12:16 PM, James Feist wrote:
>> On 11/21/19 7:39 AM, Gunnar Mills wrote:
>>>
>>> On 11/20/2019 5:50 PM, James Feist wrote:
>>>> On 11/20/19 2:45 PM, Gunnar Mills wrote:
>>>>>>>>> On 11/19/19 10:23 AM, Gunnar Mills wrote:
>>>>>>>>>>
>>>>>>>>>> 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?
>>>>>>>>>>
>>>
>>> DMTF’s Redfish
>>>
>>> They have an open forum here,  to ask questions and request 
>>> features: https://redfishforum.com/
>>>
>>> To get access to the Redfish code repository and meetings
>>> 1) Your company must be a Redfish Supporter or Promoter, a lot of 
>>> companies working on OpenBMC are
>>> 2) Join the DMTF, www.dmtf.org/join
>>> 3) Join the "Redfish Forum" working group, 
>>> https://members.dmtf.org/apps/org/workgroup/portal/
>>> 4) Send an email asking for access to the Redfish code repository
>>>
>>> I was thinking either of these would establish "engaging Redfish".
>>
>> I'd be fine with adding this to the docs/readme, however as your 
>> company has to be a supporter, it should probably be a weak requirement.
>>
> Added to the DEVELOPING.md here 
> https://gerrit.openbmc-project.xyz/c/openbmc/bmcweb/+/27480/
>
> The Redfish Specification Forum, https://redfishforum.com/  is public. 
> Anyone can request features there.
>
Still seems like it is too easy to add Redfish "OpenBMC" OEM and they 
just slip in.

Did we engage Redfish on this one 
https://gerrit.openbmc-project.xyz/c/openbmc/bmcweb/+/28699 ?

Should the schema go in a different repo, and have a different review 
process? Maybe a minimum of N contributing companies have to sign off on 
the interface definition of a Redfish "OpenBMC" OEM? Do others have a 
similar concern?

Thanks!
Gunnar

Re: Redfish OpenBMC OEM

[James Feist]

> Did we engage Redfish on this one 
> https://gerrit.openbmc-project.xyz/c/openbmc/bmcweb/+/28699 ?

Yes, from the comments:

"Was this brought up to DMTF? 
https://github.com/openbmc/bmcweb/commit/40d68ef6ebe088e4cd0078f8ff4910ca58f2be5d

I've created new thread on Redfish forum:
https://redfishforum.com/thread/273/extending-virtualmedia-schema-proposal"

> 
> Should the schema go in a different repo, and have a different review 
> process? Maybe a minimum of N contributing companies have to sign off on 
> the interface definition of a Redfish "OpenBMC" OEM? Do others have a 
> similar concern?
> 
> Thanks!
> Gunnar
> 

Re: Redfish OpenBMC OEM

[Gunnar Mills]

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


On 1/29/2020 11:20 AM, James Feist wrote:
>
> Yes, from the comments:
>
> "Was this brought up to DMTF? 
> https://github.com/openbmc/bmcweb/commit/40d68ef6ebe088e4cd0078f8ff4910ca58f2be5d
>
> I've created new thread on Redfish forum:
> https://redfishforum.com/thread/273/extending-virtualmedia-schema-proposal" 
>

I am confused by the reply (3rd comment) on 
https://redfishforum.com/thread/273/extending-virtualmedia-schema-proposal
Aren't you asking Redfish for a way to support Virtual Media via 
WebSockets? What is called "Proxy Mode" in 
https://github.com/openbmc/docs/blob/master/designs/VirtualMedia.md. 
This would be the communication between bmcweb and the browser. 
"WebSocket is a computer communications protocol, providing full-duplex 
communication channels over a single TCP connection."

Isn't the "VirtualMedia" in the Redfish ManagerNetworkProtocol schema a 
start?


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