Hi All,

Adding one more problem here with settings infra and with some proposed 
solutions.

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