Re: Using bios-settings-mgr for setting hypervisor network attributes

[Deepak Kodihalli <dkodihal@linux.vnet.ibm.com>]

On 22/09/20 2:39 pm, Ratan Gupta wrote:
> Hi All,
> 
> Adding one more problem here with settings infra and with some proposed 
> solutions.

Hi Ratan,

Thanks for bringing this problem out!

> Problem Domain:
> 
>        - With multi property update from redfish , webserver updates the 
> settings object
>        - PLDM on bmc listens on the property update of settings object 
> and notifies to Hypervisor

To add to this, from a PLDM perspective, we plan to send up the 
hypervisor network config properties to the host as BIOS attributes. 
There isn't a PLDM network config schema. The PLDM daemon talks to the 
new bios-settings-mgr app to find BIOS properties that have been updated 
out of band. The Redfish schema we plan to use here is EthernetInterface 
though, and not the Redfish BIOS schema. All this is causing a need for 
some conversion layers.

My initial thought was bmcweb can update the BIOS backend store that's 
implemented by the bios-settings-mgr, but it looks like Patrick and Ed 
have concerns with that approach. I think I agree their reasoning, but 
at the same time I don't think there should be special code in the PLDM 
daemon (timers/special knowledge about a set of BIOS attributes/special 
BIOS attribute which indicates other BIOS attributes have been 
updated/etc) for this, and this should be processed like any other BIOS 
attribute that the PLDM daemon deals with. This implies these attributes 
should also make it to the store that bios-settings-mgr owns (that 
likely means an additional D-Bus hop). So, another option (proposal 4) 
could be an intermediate app that accumulates (for eg by means of 
watching the 'Enabled' property that's in the Object.Enable interface; 
the hypervisor settings object would have to additionally implement this 
interface) the hypervisor network config property updates, and then 
provides these as key-value pairs to the bios-settings-mgr app.

>        - As there can be multiple properties in single PATCH operation, 
> PLDM on bmc sends
>          multiple Notifications to Hypervisor
>        - Specifically in case of network config,  single property update 
> on phyp may lead to network inconsistency.
> 
> How can we solve this?
> 
>   * Proposal 1: Add one more property in the settings Dbus object itself
>     which tells that it is ready to be read, PLDM on the BMC watching on
>     that property and read the whole network configuration and notifies
>     Hypervisor.
> 
>   * Proposal 2: Hypervisor runs the timer if the bios attr belongs to
>     network configuration and once the timer expires,it reads the bios
>     attr related to network and applies it.
> 
>   * Proposal 3: Add one more bios attribute in the bios table which
>     tells that Bios configuration can be read and applied by the
>     Hypervisor for the network configuration.
> 
> 
>    Looking for suggestion what could be the best way here?
> 
> Ratan
> 
> On 9/19/20 11:11 AM, Ratan Gupta wrote:
>>
>> On 9/17/20 9:06 PM, Patrick Williams wrote:
>>> On Thu, Sep 17, 2020 at 01:10:06PM +0530, Ratan Gupta wrote:
>>>> We need to address the below two concerns with the existing settings 
>>>> infra.
>>> Both of these seem like missing features based on our now greater
>>> understanding of the problem domain from where we were 3-4 years ago
>>> when phosphor-settings-manager was originally written, right? That
>>> doesn't seem like a good reason to entirely throw out the approach.
>>>
>>>>    * Pending v/s configured value: Currently settings have single Dbus
>>>>      Object, Some properties which is for host firmware we need to have
>>>>      two placeholders one for Pending values and one for Configured
>>>>      values. Bios settings have this concept.
>>>>        o Should we add two Dbus objects in settings infra?
>>> This was going to be my suggestion, yes.  You could have two sets of the
>>> objects: current and pending.  'current' objects may not be written by
>>> dbus-clients.  These are the same terms used by the BIOSConfig proposal.
>> Thanks Patrick, seems reasonable to have two D-bus objects.
>>>
>>> What I am not seeing in BIOSConfig and is equally applicable here is
>>> _when_ pending is applied to current.  You will need some interface that
>>> IPMI / PLDM can call to apply those settings?  Or, do you monitor host
>>> state signals automatically?
>>>
>>>>    * Dynamic Dbus objects: Currently settings infrastructure is only 
>>>> for
>>>>      static objects, Objects which gets added on runtime, settings 
>>>> infra
>>>>      doesn't support that.
>>>>        o Eg: IP address on ethernet interface is dynamic in nature, An
>>>>          ethernet interface can have multiple IP address on it.
>>>>          considering if SLAAC is enabled(ipV6).
>>>>        o Seems this problem is common for both(settings v/s 
>>>> bios-settings)
>>> I assume these would be requested for creation by IPMI / PLDM? We could
>>> use a similar model to xyz.openbmc_project.Inventory.Manager where
>>> objects are requested for creation dynamically through a method.
>> We don't have this requirement now but in near future it is going to
>> be there, we can improve the settings infra to support this.
>>>