Re: Storing host data on the BMC

[Patrick Williams <patrick@stwcx.xyz>]

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