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