* Redfish OpenBMC OEM
@ 2019-11-19 16:23 Gunnar Mills
2019-11-19 18:03 ` Joseph Reynolds
0 siblings, 1 reply; 14+ messages in thread
From: Gunnar Mills @ 2019-11-19 16:23 UTC (permalink / raw)
To: openbmc; +Cc: james.feist, apparao.puli, jason.m.bills
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
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Redfish OpenBMC OEM
2019-11-19 16:23 Redfish OpenBMC OEM Gunnar Mills
@ 2019-11-19 18:03 ` Joseph Reynolds
2019-11-19 19:04 ` James Feist
0 siblings, 1 reply; 14+ messages in thread
From: Joseph Reynolds @ 2019-11-19 18:03 UTC (permalink / raw)
To: Gunnar Mills, openbmc; +Cc: jason.m.bills, apparao.puli, james.feist
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
>
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Redfish OpenBMC OEM
2019-11-19 18:03 ` Joseph Reynolds
@ 2019-11-19 19:04 ` James Feist
2019-11-20 15:57 ` Joseph Reynolds
0 siblings, 1 reply; 14+ messages in thread
From: James Feist @ 2019-11-19 19:04 UTC (permalink / raw)
To: Joseph Reynolds, Gunnar Mills, openbmc; +Cc: jason.m.bills, apparao.puli
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
>>
>
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Redfish OpenBMC OEM
2019-11-19 19:04 ` James Feist
@ 2019-11-20 15:57 ` Joseph Reynolds
2019-11-20 17:47 ` James Feist
0 siblings, 1 reply; 14+ messages in thread
From: Joseph Reynolds @ 2019-11-20 15:57 UTC (permalink / raw)
To: James Feist, Gunnar Mills, openbmc; +Cc: jason.m.bills, apparao.puli
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
>>>
>>
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Redfish OpenBMC OEM
2019-11-20 15:57 ` Joseph Reynolds
@ 2019-11-20 17:47 ` James Feist
2019-11-20 22:45 ` Gunnar Mills
0 siblings, 1 reply; 14+ messages in thread
From: James Feist @ 2019-11-20 17:47 UTC (permalink / raw)
To: Joseph Reynolds, Gunnar Mills, openbmc; +Cc: jason.m.bills, apparao.puli
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
>>>>
>>>
>
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Redfish OpenBMC OEM
2019-11-20 17:47 ` James Feist
@ 2019-11-20 22:45 ` Gunnar Mills
2019-11-20 23:50 ` James Feist
0 siblings, 1 reply; 14+ messages in thread
From: Gunnar Mills @ 2019-11-20 22:45 UTC (permalink / raw)
To: James Feist, Joseph Reynolds, openbmc; +Cc: jason.m.bills, apparao.puli
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
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Redfish OpenBMC OEM
2019-11-20 22:45 ` Gunnar Mills
@ 2019-11-20 23:50 ` James Feist
2019-11-21 15:39 ` Gunnar Mills
0 siblings, 1 reply; 14+ messages in thread
From: James Feist @ 2019-11-20 23:50 UTC (permalink / raw)
To: Gunnar Mills, Joseph Reynolds, openbmc; +Cc: jason.m.bills, apparao.puli
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
>
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Redfish OpenBMC OEM
2019-11-20 23:50 ` James Feist
@ 2019-11-21 15:39 ` Gunnar Mills
2019-11-21 18:16 ` James Feist
0 siblings, 1 reply; 14+ messages in thread
From: Gunnar Mills @ 2019-11-21 15:39 UTC (permalink / raw)
To: James Feist, Joseph Reynolds, openbmc; +Cc: jason.m.bills, apparao.puli
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
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Redfish OpenBMC OEM
2019-11-21 15:39 ` Gunnar Mills
@ 2019-11-21 18:16 ` James Feist
2019-11-21 19:22 ` Gunnar Mills
0 siblings, 1 reply; 14+ messages in thread
From: James Feist @ 2019-11-21 18:16 UTC (permalink / raw)
To: Gunnar Mills, Joseph Reynolds, openbmc; +Cc: jason.m.bills, apparao.puli
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
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Redfish OpenBMC OEM
2019-11-21 18:16 ` James Feist
@ 2019-11-21 19:22 ` Gunnar Mills
2019-11-22 17:17 ` Redfish OpenBMC OEM - password not accepted Joseph Reynolds
2020-01-29 16:47 ` Redfish OpenBMC OEM Gunnar Mills
0 siblings, 2 replies; 14+ messages in thread
From: Gunnar Mills @ 2019-11-21 19:22 UTC (permalink / raw)
To: James Feist, Joseph Reynolds, openbmc; +Cc: jason.m.bills, apparao.puli
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
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Redfish OpenBMC OEM - password not accepted
2019-11-21 19:22 ` Gunnar Mills
@ 2019-11-22 17:17 ` Joseph Reynolds
2020-01-29 16:47 ` Redfish OpenBMC OEM Gunnar Mills
1 sibling, 0 replies; 14+ messages in thread
From: Joseph Reynolds @ 2019-11-22 17:17 UTC (permalink / raw)
To: Gunnar Mills, James Feist, openbmc; +Cc: jason.m.bills, apparao.puli
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
>
>
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Redfish OpenBMC OEM
2019-11-21 19:22 ` Gunnar Mills
2019-11-22 17:17 ` Redfish OpenBMC OEM - password not accepted Joseph Reynolds
@ 2020-01-29 16:47 ` Gunnar Mills
2020-01-29 17:20 ` James Feist
1 sibling, 1 reply; 14+ messages in thread
From: Gunnar Mills @ 2020-01-29 16:47 UTC (permalink / raw)
To: James Feist, Joseph Reynolds, openbmc; +Cc: jason.m.bills, apparao.puli
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
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Redfish OpenBMC OEM
2020-01-29 16:47 ` Redfish OpenBMC OEM Gunnar Mills
@ 2020-01-29 17:20 ` James Feist
2020-01-29 19:42 ` Gunnar Mills
0 siblings, 1 reply; 14+ messages in thread
From: James Feist @ 2020-01-29 17:20 UTC (permalink / raw)
To: Gunnar Mills, Joseph Reynolds, openbmc; +Cc: jason.m.bills, apparao.puli
> 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
>
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Redfish OpenBMC OEM
2020-01-29 17:20 ` James Feist
@ 2020-01-29 19:42 ` Gunnar Mills
0 siblings, 0 replies; 14+ messages in thread
From: Gunnar Mills @ 2020-01-29 19:42 UTC (permalink / raw)
To: James Feist, przemyslaw.hawrylewicz.czarnowski, pawel.rapkiewicz,
openbmc
Cc: jason.m.bills, apparao.puli
[-- 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 --]
^ permalink raw reply [flat|nested] 14+ messages in thread
end of thread, other threads:[~2020-01-29 19:42 UTC | newest]
Thread overview: 14+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-11-19 16:23 Redfish OpenBMC OEM Gunnar Mills
2019-11-19 18:03 ` Joseph Reynolds
2019-11-19 19:04 ` James Feist
2019-11-20 15:57 ` Joseph Reynolds
2019-11-20 17:47 ` James Feist
2019-11-20 22:45 ` Gunnar Mills
2019-11-20 23:50 ` James Feist
2019-11-21 15:39 ` Gunnar Mills
2019-11-21 18:16 ` James Feist
2019-11-21 19:22 ` Gunnar Mills
2019-11-22 17:17 ` Redfish OpenBMC OEM - password not accepted Joseph Reynolds
2020-01-29 16:47 ` Redfish OpenBMC OEM Gunnar Mills
2020-01-29 17:20 ` James Feist
2020-01-29 19:42 ` Gunnar Mills
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.