On Tue, Sep 22, 2020 at 02:39:04PM +0530, Ratan Gupta wrote:
> 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.

The original bios config seemed to only apply settings at specific times
(ie. when the BIOS restarts) but your problem seems to indicate that
you're immediately sending settings up to the host whenever they change?

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

It is unfortunate that org.freedesktop.DBus.Properties doesn't have a
way to set multiple properties as the analogous operation to 'GetAll'.

In the case of networking, how do we handle this for the BMC settings?
Don't we have a similar situation where multiple properties are changed
via some interface and could leave the network in an unusual state?  I'm
thinking IPMI does this.

When all of our DBus objects were serial we likely never had this issue
because the request to read the properties (to send to the hypervisor)
would come behind the signal and subsequent property updates.  Now that
we're moving towards more ASIO we likely will see this kind of issue
more often.  I don't like it but we could certainly proposal a
'SetMultiple' extension to org.freedesktop or create our own interface.

Proposal #2 isn't great because, well, how long do you wait?  In the
case of hypervisor updates, delaying something on the order of a second
is probably sufficient for Redfish/PLDM, but that doesn't really
generally solve the problem.

We could define an interface to implement something like Proposal #1,
but we would need a new interface and not a property we tack onto
existing interfaces.  We'd probably need to revisit a lot of our
interface definitions and see which ones typicallly have multi-property
updates and does an intermediate state leave us in a bad situation.

Specifically for BIOS/Hypervisor settings, I mentioned before that it
isn't clear to me what the proposal is for applying Pending to Current.
Again, this isn't general, but we could define an interface specific for
BIOS/Hypervisor settings which has a way to indicate 'Pending
transaction is complete' (set by entities like Redfish) and 'Pending
values applied to Current' (set by entities like PLDM).  For the current
settings-style values though, this requires external interfaces to
somehow know that the setting is associated with the Host in order to do
the application, since BMC-owned properties won't have or need this.

-- 
Patrick Williams