Storing host data on the BMC

Storing host data on the BMC

[Sunitha Harish]

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

Hi,

We have some user defined host settings which we are presently keeping it
in phosphor-settings-manager and the associated pldm bios attributes are
there in the pldm BIOS table. Few properties in the object hosted by the
phosphor-settings-manager are read-only for out of band but through in-band
it can be changed.

For example; the IP origin (static/dhcp) in the below commit.
https://gerrit.openbmc-project.xyz/#/c/openbmc/meta-ibm/+/30205/

UseCase: The redfish client will set the hypervisor IP address via bmcweb.
This will be taken to the hypervisor via pldm. Once the system is powered
on, the hypervisor will apply the IP address to its Ethernet Interface.
Properties like IPAddress, SubnetMask, Gateway are having one to one
mapping in the PLDM BIOS attr table and Dbus object properties, Now concern
here is on the Origin property which PLDM reads as sensor from Hypervisor.

We have two views on this scenario.
View 1: These are not suitable to be stored in the existing
phopsphor-settings-manager since these are not the writable out-of-band
user settings.
View 2: These sensors can be part of this settings table, can be considered
as a read-only attribute for the out-of-band access. These can be writable
to the host.

I understand that there are some efforts going on by Intel to come up with
internal Bios settings table but this problem is agnostic to whether we
keep the data in settings Dbus object or in the new app which is array of
key-value pairs.

Below are the two solutions which i can think of:
-------------------------------------------------------------
1. Let there be an attribute in the existing BIOS attribute table (Settings
Storage), which will be settable from the hypervisor through PLDM, however
pldm reads it as a sensor.This setting will be read-only for the
out-of-band clients(redfish). This approach is something similar to the
redfish schema, where we implement the writable & read-only attributes in
the same schema/resource. Redfish also has the origin as a settings but
they made it as a read-only attribute. This helps in bringing the related
attributes together under same object.

2. Let create a new table/object for mapping of pldm sensors ; the Sensors
Storage table which will contain only those attributes which are mapped to
the pldm sensors. This sensor table can be set by the pldm, and other
interested components can read this to get the required attribute values.
If we do this, then openBMC would be having two tables 1) Settings Storage
for Bios settings 2) Sensors Storage for pldm sensors. It is kind of
bringing the pldm complexities to the external application. Also
complexities involved in bringing the related attributes together from two
different tables.

Please let me know your views on these.  What could be the better long term
solution for this?
It would be great if you can propose any other way of handling this.

Thanks & regards,
Sunitha

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

Re: Storing host data on the BMC

[Deepak Kodihalli]

On 04/05/20 8:22 pm, Sunitha Harish wrote:
> Hi,
> 
> We have some user defined host settings which we are presently keeping 
> it in phosphor-settings-manager and the associated pldm bios attributes 
> are there in the pldm BIOS table. Few properties in the object hosted by 
> the phosphor-settings-manager are read-only for out of band but through 
> in-band it can be changed.
> 
> For example; the IP origin (static/dhcp) in the below commit.
> https://gerrit.openbmc-project.xyz/#/c/openbmc/meta-ibm/+/30205/

Is the Origin property here a host setting/BIOS attribute? I don't 
believe it is. From a PLDM perspective, this is a sensor that the host 
can update and notify the BMC via an event, for eg. Even if you make it 
read-only, it is not a setting for the host firmware - which is what 
BIOS attributes are meant for.

Thanks,
Deepak

Re: Storing host data on the BMC

[Sunitha Harish]

Hi Deepak,

As mentioned , the Origin is the property which will be set by the host 
once the IP address is applied to its interface. Its a read-only 
property for the out-of-band user. But its a closely coupled - related 
attribute on the host setting/BIOS object.

I am looking for the opinion on the two approaches proposed ; so that we 
can handle these kind of scenarios.

Thanks & regards,
Sunitha


On 04-05-2020 21:26, Deepak Kodihalli wrote:
> On 04/05/20 8:22 pm, Sunitha Harish wrote:
>> Hi,
>>
>> We have some user defined host settings which we are presently 
>> keeping it in phosphor-settings-manager and the associated pldm bios 
>> attributes are there in the pldm BIOS table. Few properties in the 
>> object hosted by the phosphor-settings-manager are read-only for out 
>> of band but through in-band it can be changed.
>>
>> For example; the IP origin (static/dhcp) in the below commit.
>> https://gerrit.openbmc-project.xyz/#/c/openbmc/meta-ibm/+/30205/
>
> Is the Origin property here a host setting/BIOS attribute? I don't 
> believe it is. From a PLDM perspective, this is a sensor that the host 
> can update and notify the BMC via an event, for eg. Even if you make 
> it read-only, it is not a setting for the host firmware - which is 
> what BIOS attributes are meant for.
>
> Thanks,
> Deepak

Re: Storing host data on the BMC

[Deepak Kodihalli]

On 05/05/20 12:12 pm, Sunitha Harish wrote:
> Hi Deepak,
> 
> As mentioned , the Origin is the property which will be set by the host 
> once the IP address is applied to its interface. Its a read-only 
> property for the out-of-band user. But its a closely coupled - related 
> attribute on the host setting/BIOS object.

Hi Sunitha,

What I'm trying to say is - we shouldn't make this coupling. The BIOS 
settings table is a group of attributes that can alter the default 
behavior of the host firmware. The Origin property you describe doesn't 
fit that description.

The host "sets" several things for the BMC, for eg the host firmware can 
tell us functional/presence states of FRUs which the host has access to. 
Everything that the host "sets" this way isn't a BIOS attribute. Once 
you decouple this, I believe we can think about options other than the 
two you have suggested - since both of them involve making the Origin 
property seem like a BIOS attribute, which it clearly is not.

Thanks,
Deepak

Re: Storing host data on the BMC

[Sunitha Harish]

Hi Deepak,

Please suggest which other approach you think is better here for Origin 
attribute?

When the interface is set as DHCPEnabled=true ; similar to the Origin 
attribute , the IP address, SubnetMask and Gateway will be set by the 
host. So we would need to consider this usecase also as a candidate for 
the new approach.

Thanks & regards,
Sunitha


On 05-05-2020 12:29, Deepak Kodihalli wrote:
> On 05/05/20 12:12 pm, Sunitha Harish wrote:
>> Hi Deepak,
>>
>> As mentioned , the Origin is the property which will be set by the 
>> host once the IP address is applied to its interface. Its a read-only 
>> property for the out-of-band user. But its a closely coupled - 
>> related attribute on the host setting/BIOS object.
>
> Hi Sunitha,
>
> What I'm trying to say is - we shouldn't make this coupling. The BIOS 
> settings table is a group of attributes that can alter the default 
> behavior of the host firmware. The Origin property you describe 
> doesn't fit that description.
>
> The host "sets" several things for the BMC, for eg the host firmware 
> can tell us functional/presence states of FRUs which the host has 
> access to. Everything that the host "sets" this way isn't a BIOS 
> attribute. Once you decouple this, I believe we can think about 
> options other than the two you have suggested - since both of them 
> involve making the Origin property seem like a BIOS attribute, which 
> it clearly is not.
>
> Thanks,
> Deepak

Re: Storing host data on the BMC

[Sunitha Harish]

Hi,

Gentle reminder for the feedback.

Thanks & regards,
Sunitha

On 06-05-2020 12:53, Sunitha Harish wrote:
> Hi Deepak,
>
> Please suggest which other approach you think is better here for 
> Origin attribute?
>
> When the interface is set as DHCPEnabled=true ; similar to the Origin 
> attribute , the IP address, SubnetMask and Gateway will be set by the 
> host. So we would need to consider this usecase also as a candidate 
> for the new approach.
>
> Thanks & regards,
> Sunitha
>
>
> On 05-05-2020 12:29, Deepak Kodihalli wrote:
>> On 05/05/20 12:12 pm, Sunitha Harish wrote:
>>> Hi Deepak,
>>>
>>> As mentioned , the Origin is the property which will be set by the 
>>> host once the IP address is applied to its interface. Its a 
>>> read-only property for the out-of-band user. But its a closely 
>>> coupled - related attribute on the host setting/BIOS object.
>>
>> Hi Sunitha,
>>
>> What I'm trying to say is - we shouldn't make this coupling. The BIOS 
>> settings table is a group of attributes that can alter the default 
>> behavior of the host firmware. The Origin property you describe 
>> doesn't fit that description.
>>
>> The host "sets" several things for the BMC, for eg the host firmware 
>> can tell us functional/presence states of FRUs which the host has 
>> access to. Everything that the host "sets" this way isn't a BIOS 
>> attribute. Once you decouple this, I believe we can think about 
>> options other than the two you have suggested - since both of them 
>> involve making the Origin property seem like a BIOS attribute, which 
>> it clearly is not.
>>
>> Thanks,
>> Deepak

Re: Storing host data on the BMC

[Patrick Williams]

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

Hello Sunitha,

Intel has already made significant progress on this problem domain and
we seem to be fairly converged on the design direction [1,2].  Have you
read through their design proposal?  Are there any oversights in their
design that would affect your needs?

Their design has been on-going for months now.  I don't think it is
appropriate to start from scratch on the design discussions unless there
is something fundamentally broken about their direction.

1. https://gerrit.openbmc-project.xyz/c/openbmc/docs/+/29320
2. https://gerrit.openbmc-project.xyz/c/openbmc/phosphor-dbus-interfaces/+/18242

I thought there was even some implementation started in bmcweb for this
feature.

On Mon, May 11, 2020 at 11:44:35AM +0530, Sunitha Harish wrote:
> Hi,
> 
> Gentle reminder for the feedback.
> 
> Thanks & regards,
> Sunitha
> 
> On 06-05-2020 12:53, Sunitha Harish wrote:
> > Hi Deepak,
> >
> > Please suggest which other approach you think is better here for 
> > Origin attribute?
> >
> > When the interface is set as DHCPEnabled=true ; similar to the Origin 
> > attribute , the IP address, SubnetMask and Gateway will be set by the 
> > host. So we would need to consider this usecase also as a candidate 
> > for the new approach.
> >
> > Thanks & regards,
> > Sunitha
> >
> >
> > On 05-05-2020 12:29, Deepak Kodihalli wrote:
> >> On 05/05/20 12:12 pm, Sunitha Harish wrote:
> >>> Hi Deepak,
> >>>
> >>> As mentioned , the Origin is the property which will be set by the 
> >>> host once the IP address is applied to its interface. Its a 
> >>> read-only property for the out-of-band user. But its a closely 
> >>> coupled - related attribute on the host setting/BIOS object.
> >>
> >> Hi Sunitha,
> >>
> >> What I'm trying to say is - we shouldn't make this coupling. The BIOS 
> >> settings table is a group of attributes that can alter the default 
> >> behavior of the host firmware. The Origin property you describe 
> >> doesn't fit that description.
> >>
> >> The host "sets" several things for the BMC, for eg the host firmware 
> >> can tell us functional/presence states of FRUs which the host has 
> >> access to. Everything that the host "sets" this way isn't a BIOS 
> >> attribute. Once you decouple this, I believe we can think about 
> >> options other than the two you have suggested - since both of them 
> >> involve making the Origin property seem like a BIOS attribute, which 
> >> it clearly is not.
> >>
> >> Thanks,
> >> Deepak

-- 
Patrick Williams

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

Re: Storing host data on the BMC

[Sunitha Harish]

Hi Patrick,

Thanks for sharing the pointers. I was aware that there was work going 
on in this area. So was looking for your and Surya's inputs on this.

I will go through these designs from my use-case perspective.

Thanks & regards,
Sunitha


On 11-05-2020 17:37, Patrick Williams wrote:
> Hello Sunitha,
>
> Intel has already made significant progress on this problem domain and
> we seem to be fairly converged on the design direction [1,2].  Have you
> read through their design proposal?  Are there any oversights in their
> design that would affect your needs?
>
> Their design has been on-going for months now.  I don't think it is
> appropriate to start from scratch on the design discussions unless there
> is something fundamentally broken about their direction.
>
> 1. https://gerrit.openbmc-project.xyz/c/openbmc/docs/+/29320
> 2. https://gerrit.openbmc-project.xyz/c/openbmc/phosphor-dbus-interfaces/+/18242
>
> I thought there was even some implementation started in bmcweb for this
> feature.
>
> On Mon, May 11, 2020 at 11:44:35AM +0530, Sunitha Harish wrote:
>> Hi,
>>
>> Gentle reminder for the feedback.
>>
>> Thanks & regards,
>> Sunitha
>>
>> On 06-05-2020 12:53, Sunitha Harish wrote:
>>> Hi Deepak,
>>>
>>> Please suggest which other approach you think is better here for
>>> Origin attribute?
>>>
>>> When the interface is set as DHCPEnabled=true ; similar to the Origin
>>> attribute , the IP address, SubnetMask and Gateway will be set by the
>>> host. So we would need to consider this usecase also as a candidate
>>> for the new approach.
>>>
>>> Thanks & regards,
>>> Sunitha
>>>
>>>
>>> On 05-05-2020 12:29, Deepak Kodihalli wrote:
>>>> On 05/05/20 12:12 pm, Sunitha Harish wrote:
>>>>> Hi Deepak,
>>>>>
>>>>> As mentioned , the Origin is the property which will be set by the
>>>>> host once the IP address is applied to its interface. Its a
>>>>> read-only property for the out-of-band user. But its a closely
>>>>> coupled - related attribute on the host setting/BIOS object.
>>>> Hi Sunitha,
>>>>
>>>> What I'm trying to say is - we shouldn't make this coupling. The BIOS
>>>> settings table is a group of attributes that can alter the default
>>>> behavior of the host firmware. The Origin property you describe
>>>> doesn't fit that description.
>>>>
>>>> The host "sets" several things for the BMC, for eg the host firmware
>>>> can tell us functional/presence states of FRUs which the host has
>>>> access to. Everything that the host "sets" this way isn't a BIOS
>>>> attribute. Once you decouple this, I believe we can think about
>>>> options other than the two you have suggested - since both of them
>>>> involve making the Origin property seem like a BIOS attribute, which
>>>> it clearly is not.
>>>>
>>>> Thanks,
>>>> Deepak

Re: Storing host data on the BMC

[Sunitha Harish]

Hi Patrick/Surya,

Seems to me that the design which Intel proposed does not cover the 
scenario which i was mentioning about.

My scenario is :
1. Redfish client sets the host interface parameters for the IPv4 
address. These user settable values are stored in the DBus.
2. When the system is powered on , the pldm reads these DBus values , 
and sets the BIOS attributes.
3. The hypervisor reads this BIOS attributes for the interfaces and sets 
them.
4. Now the hypervisor sends an indication to the pldm that the IP 
address is active at its interface and its Origin is Static ( ie : user 
configured) OR it is DHCP ( ie: not user configured, if its DHCP enabled)
5. The pldm should store this Origin value "somewhere".

Redfish client would need this value to interpret where the IP address 
has been Originated from. So we need a DBus property to save it. But , 
this is actually an attribute which is set by the hypervisor/host - a 
pldm sensor. Its not suitable to be fit into the BIOS table. My 
question&proposal is about how/where to store this value?

Thanks & regards,
Sunitha


On 11-05-2020 21:35, Sunitha Harish wrote:
> Hi Patrick,
>
> Thanks for sharing the pointers. I was aware that there was work going 
> on in this area. So was looking for your and Surya's inputs on this.
>
> I will go through these designs from my use-case perspective.
>
> Thanks & regards,
> Sunitha
>
>
> On 11-05-2020 17:37, Patrick Williams wrote:
>> Hello Sunitha,
>>
>> Intel has already made significant progress on this problem domain and
>> we seem to be fairly converged on the design direction [1,2]. Have you
>> read through their design proposal?  Are there any oversights in their
>> design that would affect your needs?
>>
>> Their design has been on-going for months now.  I don't think it is
>> appropriate to start from scratch on the design discussions unless there
>> is something fundamentally broken about their direction.
>>
>> 1. https://gerrit.openbmc-project.xyz/c/openbmc/docs/+/29320
>> 2. 
>> https://gerrit.openbmc-project.xyz/c/openbmc/phosphor-dbus-interfaces/+/18242
>>
>> I thought there was even some implementation started in bmcweb for this
>> feature.
>>
>> On Mon, May 11, 2020 at 11:44:35AM +0530, Sunitha Harish wrote:
>>> Hi,
>>>
>>> Gentle reminder for the feedback.
>>>
>>> Thanks & regards,
>>> Sunitha
>>>
>>> On 06-05-2020 12:53, Sunitha Harish wrote:
>>>> Hi Deepak,
>>>>
>>>> Please suggest which other approach you think is better here for
>>>> Origin attribute?
>>>>
>>>> When the interface is set as DHCPEnabled=true ; similar to the Origin
>>>> attribute , the IP address, SubnetMask and Gateway will be set by the
>>>> host. So we would need to consider this usecase also as a candidate
>>>> for the new approach.
>>>>
>>>> Thanks & regards,
>>>> Sunitha
>>>>
>>>>
>>>> On 05-05-2020 12:29, Deepak Kodihalli wrote:
>>>>> On 05/05/20 12:12 pm, Sunitha Harish wrote:
>>>>>> Hi Deepak,
>>>>>>
>>>>>> As mentioned , the Origin is the property which will be set by the
>>>>>> host once the IP address is applied to its interface. Its a
>>>>>> read-only property for the out-of-band user. But its a closely
>>>>>> coupled - related attribute on the host setting/BIOS object.
>>>>> Hi Sunitha,
>>>>>
>>>>> What I'm trying to say is - we shouldn't make this coupling. The BIOS
>>>>> settings table is a group of attributes that can alter the default
>>>>> behavior of the host firmware. The Origin property you describe
>>>>> doesn't fit that description.
>>>>>
>>>>> The host "sets" several things for the BMC, for eg the host firmware
>>>>> can tell us functional/presence states of FRUs which the host has
>>>>> access to. Everything that the host "sets" this way isn't a BIOS
>>>>> attribute. Once you decouple this, I believe we can think about
>>>>> options other than the two you have suggested - since both of them
>>>>> involve making the Origin property seem like a BIOS attribute, which
>>>>> it clearly is not.
>>>>>
>>>>> Thanks,
>>>>> Deepak

Re: Storing host data on the BMC

[Deepak Kodihalli]

On 13/05/20 8:37 pm, Sunitha Harish wrote:


> Redfish client would need this value to interpret where the IP address 
> has been Originated from. So we need a DBus property to save it.

Makes sense.

> this is actually an attribute which is set by the hypervisor/host - a 
> pldm sensor. Its not suitable to be fit into the BIOS table.

Agree.

> My question&proposal is about how/where to store this value?

Anywhere but the BIOS attributes store on D-Bus? For eg could you come 
up with another D-Bus interface to house this property? The PLDM demon 
can relay a PLDM sensor to a D-Bus object that implements this property. 
There are other PLDM sensors that the host owns, that are already 
handled this way today - the host updates a PLDM sensor and lets the BMC 
know about it. The BMC can update a corresponding D-Bus property.

> Thanks & regards,
> Sunitha

Re: Storing host data on the BMC

[Patrick Williams]

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

On Wed, May 13, 2020 at 08:37:32PM +0530, Sunitha Harish wrote:
> My scenario is :
> 1. Redfish client sets the host interface parameters for the IPv4 
> address. These user settable values are stored in the DBus.

Ignoring which process "stores" this data, we have two mechanisms over
DBus to store this kind of data.  I can't tell fully from your
explaination which is more appropriate for this data.

1. Data we want to split out into well-formed, existing dbus objects.

    * We already have interfaces to store networking information under
      xyz/openbmc_project/Network.

2. Data which is generic / opaque to the BMC and we're just using the
   BMC as a "storage location".

   * This would be the proposed BIOS attributes interface.

So the question to you is, do you want the BMC to actively interact with
and manage this data, like we do for our own data, or do you want the
BMC to just be a dumb passthru of this data?

> 2. When the system is powered on , the pldm reads these DBus values , 
> and sets the BIOS attributes.
> 3. The hypervisor reads this BIOS attributes for the interfaces and sets 
> them.

It doesn't seem like two steps matter with respect to the 1/2 above.
Where the data is obtained in this regard can be self-contained in your
PLDM provider, correct?

> 4. Now the hypervisor sends an indication to the pldm that the IP 
> address is active at its interface and its Origin is Static ( ie : user 
> configured) OR it is DHCP ( ie: not user configured, if its DHCP enabled)
> 5. The pldm should store this Origin value "somewhere".

This description makes it seem like you want it to be more "managed"
data than "opaque", if I'm reading this correctly.

> Redfish client would need this value to interpret where the IP address 
> has been Originated from. So we need a DBus property to save it. But , 
> this is actually an attribute which is set by the hypervisor/host - a 
> pldm sensor. Its not suitable to be fit into the BIOS table. My 
> question&proposal is about how/where to store this value?

I think we need to be careful about being hung up on the name "BIOS
table".  For opaque data that is more OS-centric,  we could  make the
proposed "BIOS Attributes" interface more generic to store different
levels of host-owned data: BIOS, Hypervisor, OS.  This might be a good
comment to make on the interface code review.

If you are wanting the data to be managed, utilizing existing DBus
interfaces we have around networking, doesn't phosphor-settingsd cover
that from an implementation perspective?

-- 
Patrick Williams

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

Re: Storing host data on the BMC

[Deepak Kodihalli]

On 14/05/20 2:48 am, Patrick Williams wrote:
> On Wed, May 13, 2020 at 08:37:32PM +0530, Sunitha Harish wrote:
>> My scenario is :
>> 1. Redfish client sets the host interface parameters for the IPv4
>> address. These user settable values are stored in the DBus.
> 
> Ignoring which process "stores" this data, we have two mechanisms over
> DBus to store this kind of data.  I can't tell fully from your
> explaination which is more appropriate for this data.
> 
> 1. Data we want to split out into well-formed, existing dbus objects.
> 
>      * We already have interfaces to store networking information under
>        xyz/openbmc_project/Network.
> 
> 2. Data which is generic / opaque to the BMC and we're just using the
>     BMC as a "storage location".
> 
>     * This would be the proposed BIOS attributes interface.
> 
> So the question to you is, do you want the BMC to actively interact with
> and manage this data, like we do for our own data, or do you want the
> BMC to just be a dumb passthru of this data?
> 
>> 2. When the system is powered on , the pldm reads these DBus values ,
>> and sets the BIOS attributes.
>> 3. The hypervisor reads this BIOS attributes for the interfaces and sets
>> them.
> 
> It doesn't seem like two steps matter with respect to the 1/2 above.
> Where the data is obtained in this regard can be self-contained in your
> PLDM provider, correct?
> 
>> 4. Now the hypervisor sends an indication to the pldm that the IP
>> address is active at its interface and its Origin is Static ( ie : user
>> configured) OR it is DHCP ( ie: not user configured, if its DHCP enabled)
>> 5. The pldm should store this Origin value "somewhere".
> 
> This description makes it seem like you want it to be more "managed"
> data than "opaque", if I'm reading this correctly.
> 
>> Redfish client would need this value to interpret where the IP address
>> has been Originated from. So we need a DBus property to save it. But ,
>> this is actually an attribute which is set by the hypervisor/host - a
>> pldm sensor. Its not suitable to be fit into the BIOS table. My
>> question&proposal is about how/where to store this value?
> 
> I think we need to be careful about being hung up on the name "BIOS
> table".  For opaque data that is more OS-centric,  we could  make the
> proposed "BIOS Attributes" interface more generic to store different
> levels of host-owned data: BIOS, Hypervisor, OS.  This might be a good
> comment to make on the interface code review.

I think the current proposal from Surya enables this already. Do you 
just mean the design doc should explicitly state this isn't restricted 
to the "BIOS" firmware.

As far as Sunitha's question goes, my point is that not all host 
firmware generated data is a BIOS attribute. For eg if the host tells me 
about the presence of certain FRUs, or their functional states, I 
wouldn't want to store those in the BIOS attributes backend, I'd rather 
associates those with the existing D-Bus interfaces for the FRU 
inventory. I think the same applies to the Origin property that has been 
described - associate with the networking D-Bus backend.

> If you are wanting the data to be managed, utilizing existing DBus
> interfaces we have around networking, doesn't phosphor-settingsd cover
> that from an implementation perspective?

I don't think the 'Origin' property is a setting.

Regards,
Deepak

Re: Storing host data on the BMC

[Patrick Williams]

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

On Thu, May 14, 2020 at 09:13:47AM +0530, Deepak Kodihalli wrote:
> On 14/05/20 2:48 am, Patrick Williams wrote:
> > On Wed, May 13, 2020 at 08:37:32PM +0530, Sunitha Harish wrote:
 
> I think the current proposal from Surya enables this already. Do you 
> just mean the design doc should explicitly state this isn't restricted 
> to the "BIOS" firmware.

Yep.

> As far as Sunitha's question goes, my point is that not all host 
> firmware generated data is a BIOS attribute. For eg if the host tells me 
> about the presence of certain FRUs, or their functional states, I 
> wouldn't want to store those in the BIOS attributes backend, I'd rather 
> associates those with the existing D-Bus interfaces for the FRU 
> inventory. I think the same applies to the Origin property that has been 
> described - associate with the networking D-Bus backend.

I think we're in agreement here.  Data which is interesting to represent
on the BMC, for which we already have a defined-interface, use it.  For
data which isn't interesting the to BMC, use the generic BIOS attribute
table.

> > If you are wanting the data to be managed, utilizing existing DBus
> > interfaces we have around networking, doesn't phosphor-settingsd cover
> > that from an implementation perspective?
> 
> I don't think the 'Origin' property is a setting.

Well the name "settingsd" is somewhat arbitrary based on its original
definition.  I believe the current implementation can make a placeholder
instance of any dbus interface.

Having said that, one weakness with settingsd is that you can't easily
restrict property changes to data coming from the host.  Once you make a
settingsd object, anyone can make dbus calls to change properties on it.
If we want to be able to restrict that to specific interfaces, we might
want to look at a phosphor-inventory-manager like implementation which
has a special "backdoor" method to create / update the instances but
prevents modification through the normal property change interfaces.

-- 
Patrick Williams

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

Re: Storing host data on the BMC

[Sunitha Harish]

Thanks Deepak & Patrick.

So the preferred approach would be to define the host settable data in a 
new phosphor-host-inventory-manager, and make this as read-only to the 
other BMC applications.

The Interface: xyz.openbmc_project.Network.EthernetInterface - 
DHCPEnabled property is a Bios attribute. 
https://gerrit.openbmc-project.xyz/#/c/openbmc/meta-ibm/+/30424/
Lets take a scenario - when the Ethernet interface set to be DHCP 
enabled ( by setting the DHCPEnabled = true via redfish), the IPAddress, 
SubnetMask and Gateway along with the Origin property will not be BIOS 
one as all they can't be settable by the redfish in the case of DHCP and 
they will be part of this new manager.

However in the case of Static IP configuration(IPAddress, SubnetMask and 
Gateway) will become bios setting.

Would we be having these attributes in both Bios table and in the new 
settings manager ?

By considering all these , can you please weigh in your thoughts about 
extending the existing settings interface table, by defining the 
attribute as read-only for BMC ? We can block the "write" to these 
attributes at user level. This would make things simpler , and it will 
be in line with the redfish interface definitions as well. Redfish 
already defines the schema where it makes some attributes read-only for 
the users.

Thanks & regards,
Sunitha


On 14-05-2020 18:03, Patrick Williams wrote:
> On Thu, May 14, 2020 at 09:13:47AM +0530, Deepak Kodihalli wrote:
>> On 14/05/20 2:48 am, Patrick Williams wrote:
>>> On Wed, May 13, 2020 at 08:37:32PM +0530, Sunitha Harish wrote:
>   
>> I think the current proposal from Surya enables this already. Do you
>> just mean the design doc should explicitly state this isn't restricted
>> to the "BIOS" firmware.
> Yep.
>
>> As far as Sunitha's question goes, my point is that not all host
>> firmware generated data is a BIOS attribute. For eg if the host tells me
>> about the presence of certain FRUs, or their functional states, I
>> wouldn't want to store those in the BIOS attributes backend, I'd rather
>> associates those with the existing D-Bus interfaces for the FRU
>> inventory. I think the same applies to the Origin property that has been
>> described - associate with the networking D-Bus backend.
> I think we're in agreement here.  Data which is interesting to represent
> on the BMC, for which we already have a defined-interface, use it.  For
> data which isn't interesting the to BMC, use the generic BIOS attribute
> table.
>
>>> If you are wanting the data to be managed, utilizing existing DBus
>>> interfaces we have around networking, doesn't phosphor-settingsd cover
>>> that from an implementation perspective?
>> I don't think the 'Origin' property is a setting.
> Well the name "settingsd" is somewhat arbitrary based on its original
> definition.  I believe the current implementation can make a placeholder
> instance of any dbus interface.
>
> Having said that, one weakness with settingsd is that you can't easily
> restrict property changes to data coming from the host.  Once you make a
> settingsd object, anyone can make dbus calls to change properties on it.
> If we want to be able to restrict that to specific interfaces, we might
> want to look at a phosphor-inventory-manager like implementation which
> has a special "backdoor" method to create / update the instances but
> prevents modification through the normal property change interfaces.
>

Re: Storing host data on the BMC

[Sunitha Harish]

Hi,

Any inputs?

Thanks & regards,
Sunitha

On 18-05-2020 17:23, Sunitha Harish wrote:
> Thanks Deepak & Patrick.
>
> So the preferred approach would be to define the host settable data in 
> a new phosphor-host-inventory-manager, and make this as read-only to 
> the other BMC applications.
>
> The Interface: xyz.openbmc_project.Network.EthernetInterface - 
> DHCPEnabled property is a Bios attribute. 
> https://gerrit.openbmc-project.xyz/#/c/openbmc/meta-ibm/+/30424/
> Lets take a scenario - when the Ethernet interface set to be DHCP 
> enabled ( by setting the DHCPEnabled = true via redfish), the 
> IPAddress, SubnetMask and Gateway along with the Origin property will 
> not be BIOS one as all they can't be settable by the redfish in the 
> case of DHCP and they will be part of this new manager.
>
> However in the case of Static IP configuration(IPAddress, SubnetMask 
> and Gateway) will become bios setting.
>
> Would we be having these attributes in both Bios table and in the new 
> settings manager ?
>
> By considering all these , can you please weigh in your thoughts about 
> extending the existing settings interface table, by defining the 
> attribute as read-only for BMC ? We can block the "write" to these 
> attributes at user level. This would make things simpler , and it will 
> be in line with the redfish interface definitions as well. Redfish 
> already defines the schema where it makes some attributes read-only 
> for the users.
>
> Thanks & regards,
> Sunitha
>
>
> On 14-05-2020 18:03, Patrick Williams wrote:
>> On Thu, May 14, 2020 at 09:13:47AM +0530, Deepak Kodihalli wrote:
>>> On 14/05/20 2:48 am, Patrick Williams wrote:
>>>> On Wed, May 13, 2020 at 08:37:32PM +0530, Sunitha Harish wrote:
>>> I think the current proposal from Surya enables this already. Do you
>>> just mean the design doc should explicitly state this isn't restricted
>>> to the "BIOS" firmware.
>> Yep.
>>
>>> As far as Sunitha's question goes, my point is that not all host
>>> firmware generated data is a BIOS attribute. For eg if the host 
>>> tells me
>>> about the presence of certain FRUs, or their functional states, I
>>> wouldn't want to store those in the BIOS attributes backend, I'd rather
>>> associates those with the existing D-Bus interfaces for the FRU
>>> inventory. I think the same applies to the Origin property that has 
>>> been
>>> described - associate with the networking D-Bus backend.
>> I think we're in agreement here.  Data which is interesting to represent
>> on the BMC, for which we already have a defined-interface, use it.  For
>> data which isn't interesting the to BMC, use the generic BIOS attribute
>> table.
>>
>>>> If you are wanting the data to be managed, utilizing existing DBus
>>>> interfaces we have around networking, doesn't phosphor-settingsd cover
>>>> that from an implementation perspective?
>>> I don't think the 'Origin' property is a setting.
>> Well the name "settingsd" is somewhat arbitrary based on its original
>> definition.  I believe the current implementation can make a placeholder
>> instance of any dbus interface.
>>
>> Having said that, one weakness with settingsd is that you can't easily
>> restrict property changes to data coming from the host.  Once you make a
>> settingsd object, anyone can make dbus calls to change properties on it.
>> If we want to be able to restrict that to specific interfaces, we might
>> want to look at a phosphor-inventory-manager like implementation which
>> has a special "backdoor" method to create / update the instances but
>> prevents modification through the normal property change interfaces.
>>

Re: Storing host data on the BMC

[Deepak Kodihalli]

On 21/05/20 10:42 am, Sunitha Harish wrote:
> Hi,
> 
> Any inputs?
> 
> Thanks & regards,
> Sunitha

Hi Sunitha,

I believe you had got a direction based on the discussion below.

>>>> As far as Sunitha's question goes, my point is that not all host
>>>> firmware generated data is a BIOS attribute. For eg if the host 
>>>> tells me
>>>> about the presence of certain FRUs, or their functional states, I
>>>> wouldn't want to store those in the BIOS attributes backend, I'd rather
>>>> associates those with the existing D-Bus interfaces for the FRU
>>>> inventory. I think the same applies to the Origin property that has 
>>>> been
>>>> described - associate with the networking D-Bus backend.
>>> I think we're in agreement here.  Data which is interesting to represent
>>> on the BMC, for which we already have a defined-interface, use it.  For
>>> data which isn't interesting the to BMC, use the generic BIOS attribute
>>> table.

^^ You use existing (or come up with new) D-Bus interfaces to represent 
your data. Those D-Bus interfaces can be implemented by settingsd or 
networkd or something else.

Thanks,
Deepak

Re: Storing host data on the BMC

[Sunitha Harish]

On 21-05-2020 10:46, Deepak Kodihalli wrote:
> On 21/05/20 10:42 am, Sunitha Harish wrote:
>> Hi,
>>
>> Any inputs?
>>
>> Thanks & regards,
>> Sunitha
>
> Hi Sunitha,
>
> I believe you had got a direction based on the discussion below.
>
>>>>> As far as Sunitha's question goes, my point is that not all host
>>>>> firmware generated data is a BIOS attribute. For eg if the host 
>>>>> tells me
>>>>> about the presence of certain FRUs, or their functional states, I
>>>>> wouldn't want to store those in the BIOS attributes backend, I'd 
>>>>> rather
>>>>> associates those with the existing D-Bus interfaces for the FRU
>>>>> inventory. I think the same applies to the Origin property that 
>>>>> has been
>>>>> described - associate with the networking D-Bus backend.
>>>> I think we're in agreement here.  Data which is interesting to 
>>>> represent
>>>> on the BMC, for which we already have a defined-interface, use it.  
>>>> For
>>>> data which isn't interesting the to BMC, use the generic BIOS 
>>>> attribute
>>>> table.
>
> ^^ You use existing (or come up with new) D-Bus interfaces to 
> represent your data. Those D-Bus interfaces can be implemented by 
> settingsd or networkd or something else.

If i am getting it correctly , the current changes which were made to 
the phosphor-settings-manager should be good enough to handle all the 
scenarios.

In my last email i mentioned that ===>>
--------------------------------------------------------------------------------------------------------------------------
When the Ethernet interface set to be DHCP enabled ( by setting the Bios 
attribute DHCPEnabled = true via redfish), the IPAddress, SubnetMask and 
Gateway along with the Origin property will not be Bios settings. Here 
the user will be setting the DHCPEnabled property.
However in the case of Static IP configuration(IPAddress, SubnetMask and 
Gateway) they will become bios setting.
---------------------------------------------------------------------------------------------------------------------------
Currently we are using the xyz.openbmc_project.Network.IP and this 
interface is being implemented by settings object - 
https://gerrit.openbmc-project.xyz/#/c/openbmc/meta-ibm/+/30424/

Do you see any issues here?


> Thanks,
> Deepak
>

Re: Storing host data on the BMC

[Sunitha Harish]

On 21-05-2020 10:46, Deepak Kodihalli wrote:
> On 21/05/20 10:42 am, Sunitha Harish wrote:
>> Hi,
>>
>> Any inputs?
>>
>> Thanks & regards,
>> Sunitha
>
> Hi Sunitha,
>
> I believe you had got a direction based on the discussion below.
>
>>>>> As far as Sunitha's question goes, my point is that not all host
>>>>> firmware generated data is a BIOS attribute. For eg if the host 
>>>>> tells me
>>>>> about the presence of certain FRUs, or their functional states, I
>>>>> wouldn't want to store those in the BIOS attributes backend, I'd 
>>>>> rather
>>>>> associates those with the existing D-Bus interfaces for the FRU
>>>>> inventory. I think the same applies to the Origin property that 
>>>>> has been
>>>>> described - associate with the networking D-Bus backend.
>>>> I think we're in agreement here.  Data which is interesting to 
>>>> represent
>>>> on the BMC, for which we already have a defined-interface, use it.  
>>>> For
>>>> data which isn't interesting the to BMC, use the generic BIOS 
>>>> attribute
>>>> table.
>
> ^^ You use existing (or come up with new) D-Bus interfaces to 
> represent your data. Those D-Bus interfaces can be implemented by 
> settingsd or networkd or something else.

If i am getting it correctly , the current changes which were made to 
the phosphor-settings-manager should be good enough to handle all the 
scenarios.

In my last email i mentioned that ===>>
--------------------------------------------------------------------------------------------------------------------------
When the Ethernet interface set to be DHCP enabled ( by setting the Bios 
attribute DHCPEnabled = true via redfish), the IPAddress, SubnetMask and 
Gateway along with the Origin property will not be Bios settings. Here 
the user setting is the DHCPEnabled property of ?

However in the case of Static IP configuration(IPAddress, SubnetMask and 
Gateway) they will become bios setting.
---------------------------------------------------------------------------------------------------------------------------
Currently we are using the xyz.openbmc_project.Network.IP and this 
interface is being implemented by settings object - 
https://gerrit.openbmc-project.xyz/#/c/openbmc/meta-ibm/+/30424/
Do you see any issue here?

> Thanks,
> Deepak
>

Re: Storing host data on the BMC

[Sunitha Harish]

On 22-05-2020 09:29, Sunitha Harish wrote:
>
> On 21-05-2020 10:46, Deepak Kodihalli wrote:
>> On 21/05/20 10:42 am, Sunitha Harish wrote:
>>> Hi,
>>>
>>> Any inputs?
>>>
>>> Thanks & regards,
>>> Sunitha
>>
>> Hi Sunitha,
>>
>> I believe you had got a direction based on the discussion below.
>>
>>>>>> As far as Sunitha's question goes, my point is that not all host
>>>>>> firmware generated data is a BIOS attribute. For eg if the host 
>>>>>> tells me
>>>>>> about the presence of certain FRUs, or their functional states, I
>>>>>> wouldn't want to store those in the BIOS attributes backend, I'd 
>>>>>> rather
>>>>>> associates those with the existing D-Bus interfaces for the FRU
>>>>>> inventory. I think the same applies to the Origin property that 
>>>>>> has been
>>>>>> described - associate with the networking D-Bus backend.
>>>>> I think we're in agreement here.  Data which is interesting to 
>>>>> represent
>>>>> on the BMC, for which we already have a defined-interface, use 
>>>>> it.  For
>>>>> data which isn't interesting the to BMC, use the generic BIOS 
>>>>> attribute
>>>>> table.
>>
>> ^^ You use existing (or come up with new) D-Bus interfaces to 
>> represent your data. Those D-Bus interfaces can be implemented by 
>> settingsd or networkd or something else.
>
> If i am getting it correctly , the current changes which were made to 
> the phosphor-settings-manager should be good enough to handle all the 
> scenarios.
>
> In my last email i mentioned that ===>>
> -------------------------------------------------------------------------------------------------------------------------- 
>
> When the Ethernet interface set to be DHCP enabled ( by setting the 
> Bios attribute DHCPEnabled = true via redfish), the IPAddress, 
> SubnetMask and Gateway along with the Origin property will not be Bios 
> settings. Here the user setting is the DHCPEnabled property of ?
>
> However in the case of Static IP configuration(IPAddress, SubnetMask 
> and Gateway) they will become bios setting.
> --------------------------------------------------------------------------------------------------------------------------- 
>
> Currently we are using the xyz.openbmc_project.Network.IP and this 
> interface is being implemented by settings object - 
> https://gerrit.openbmc-project.xyz/#/c/openbmc/meta-ibm/+/30424/
> Do you see any issue here?

Hi , any feedback ?

Thanks & regards,
Sunitha
>
>> Thanks,
>> Deepak
>>

Re: Storing host data on the BMC

[Deepak Kodihalli]

On 29/05/20 4:27 pm, Sunitha Harish wrote:
> 
> On 22-05-2020 09:29, Sunitha Harish wrote:
>>
>> On 21-05-2020 10:46, Deepak Kodihalli wrote:
>>> On 21/05/20 10:42 am, Sunitha Harish wrote:
>>>> Hi,
>>>>
>>>> Any inputs?
>>>>
>>>> Thanks & regards,
>>>> Sunitha
>>>
>>> Hi Sunitha,
>>>
>>> I believe you had got a direction based on the discussion below.
>>>
>>>>>>> As far as Sunitha's question goes, my point is that not all host
>>>>>>> firmware generated data is a BIOS attribute. For eg if the host 
>>>>>>> tells me
>>>>>>> about the presence of certain FRUs, or their functional states, I
>>>>>>> wouldn't want to store those in the BIOS attributes backend, I'd 
>>>>>>> rather
>>>>>>> associates those with the existing D-Bus interfaces for the FRU
>>>>>>> inventory. I think the same applies to the Origin property that 
>>>>>>> has been
>>>>>>> described - associate with the networking D-Bus backend.
>>>>>> I think we're in agreement here.  Data which is interesting to 
>>>>>> represent
>>>>>> on the BMC, for which we already have a defined-interface, use 
>>>>>> it.  For
>>>>>> data which isn't interesting the to BMC, use the generic BIOS 
>>>>>> attribute
>>>>>> table.
>>>
>>> ^^ You use existing (or come up with new) D-Bus interfaces to 
>>> represent your data. Those D-Bus interfaces can be implemented by 
>>> settingsd or networkd or something else.
>>
>> If i am getting it correctly , the current changes which were made to 
>> the phosphor-settings-manager should be good enough to handle all the 
>> scenarios.
>>
>> In my last email i mentioned that ===>>
>> -------------------------------------------------------------------------------------------------------------------------- 
>>
>> When the Ethernet interface set to be DHCP enabled ( by setting the 
>> Bios attribute DHCPEnabled = true via redfish), the IPAddress, 
>> SubnetMask and Gateway along with the Origin property will not be Bios 
>> settings. Here the user setting is the DHCPEnabled property of ?
>>
>> However in the case of Static IP configuration(IPAddress, SubnetMask 
>> and Gateway) they will become bios setting.
>> --------------------------------------------------------------------------------------------------------------------------- 
>>
>> Currently we are using the xyz.openbmc_project.Network.IP and this 
>> interface is being implemented by settings object - 
>> https://gerrit.openbmc-project.xyz/#/c/openbmc/meta-ibm/+/30424/
>> Do you see any issue here?
> 
> Hi , any feedback ?

Sorry I forgot to respond to this. If your question is whether the 
Origin property (and the interface it lies in) can be implemented by 
phosphor-settingsd, then I think the answer is yes. We did say that we 
can look at phosphor-settingsd as an arbitrary data holder (not limited 
to user settings).

> Thanks & regards,
> Sunitha
>>
>>> Thanks,
>>> Deepak
>>>

Re: Storing host data on the BMC

[Sunitha Harish]

On 29-05-2020 16:33, Deepak Kodihalli wrote:
> On 29/05/20 4:27 pm, Sunitha Harish wrote:
>>
>> On 22-05-2020 09:29, Sunitha Harish wrote:
>>>
>>> On 21-05-2020 10:46, Deepak Kodihalli wrote:
>>>> On 21/05/20 10:42 am, Sunitha Harish wrote:
>>>>> Hi,
>>>>>
>>>>> Any inputs?
>>>>>
>>>>> Thanks & regards,
>>>>> Sunitha
>>>>
>>>> Hi Sunitha,
>>>>
>>>> I believe you had got a direction based on the discussion below.
>>>>
>>>>>>>> As far as Sunitha's question goes, my point is that not all host
>>>>>>>> firmware generated data is a BIOS attribute. For eg if the host 
>>>>>>>> tells me
>>>>>>>> about the presence of certain FRUs, or their functional states, I
>>>>>>>> wouldn't want to store those in the BIOS attributes backend, 
>>>>>>>> I'd rather
>>>>>>>> associates those with the existing D-Bus interfaces for the FRU
>>>>>>>> inventory. I think the same applies to the Origin property that 
>>>>>>>> has been
>>>>>>>> described - associate with the networking D-Bus backend.
>>>>>>> I think we're in agreement here.  Data which is interesting to 
>>>>>>> represent
>>>>>>> on the BMC, for which we already have a defined-interface, use 
>>>>>>> it.  For
>>>>>>> data which isn't interesting the to BMC, use the generic BIOS 
>>>>>>> attribute
>>>>>>> table.
>>>>
>>>> ^^ You use existing (or come up with new) D-Bus interfaces to 
>>>> represent your data. Those D-Bus interfaces can be implemented by 
>>>> settingsd or networkd or something else.
>>>
>>> If i am getting it correctly , the current changes which were made 
>>> to the phosphor-settings-manager should be good enough to handle all 
>>> the scenarios.
>>>
>>> In my last email i mentioned that ===>>
>>> -------------------------------------------------------------------------------------------------------------------------- 
>>>
>>> When the Ethernet interface set to be DHCP enabled ( by setting the 
>>> Bios attribute DHCPEnabled = true via redfish), the IPAddress, 
>>> SubnetMask and Gateway along with the Origin property will not be 
>>> Bios settings. Here the user setting is the DHCPEnabled property of ?
>>>
>>> However in the case of Static IP configuration(IPAddress, SubnetMask 
>>> and Gateway) they will become bios setting.
>>> --------------------------------------------------------------------------------------------------------------------------- 
>>>
>>> Currently we are using the xyz.openbmc_project.Network.IP and this 
>>> interface is being implemented by settings object - 
>>> https://gerrit.openbmc-project.xyz/#/c/openbmc/meta-ibm/+/30424/
>>> Do you see any issue here?
>>
>> Hi , any feedback ?
>
> Sorry I forgot to respond to this. If your question is whether the 
> Origin property (and the interface it lies in) can be implemented by 
> phosphor-settingsd, then I think the answer is yes. We did say that we 
> can look at phosphor-settingsd as an arbitrary data holder (not 
> limited to user settings).

Thanks Deepak , So I believe now we can go ahead with the current 
implementation in the gerrit links :

https://gerrit.openbmc-project.xyz/#/c/openbmc/meta-ibm/+/30205/
https://gerrit.openbmc-project.xyz/#/c/openbmc/meta-ibm/+/30424/

Lets continue the review there for any further comments, and please 
provide your scores as well.

>
>> Thanks & regards,
>> Sunitha
>>>
>>>> Thanks,
>>>> Deepak
>>>>
>