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