Using bios-settings-mgr for setting hypervisor network attributes

[Ratan Gupta]

On 9/24/20 12:54 AM, Patrick Williams wrote:
> 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?
Yes, you are correct we are sending immediately to the host.
>
>> 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.

I hope you are asking for BMC network settings where we wait for a 
certain amount of time and then apply the settings,same with IPMI.

> 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.
My point was to add a property through new Dbus Interface, sorry for the 
confusion.
>
> 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.
>