Storing host data on the BMC

[Sunitha Harish]

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ozlabs.org/pipermail/openbmc/attachments/20200504/0c1674a2/attachment.htm>