Using bios-settings-mgr for setting hypervisor network attributes

[Ed Tanous]

On Wed, Sep 23, 2020 at 12:24 PM Patrick Williams <patrick at stwcx.xyz> 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?

I have a very similar use case that I will need to build out in the
next year.  Yes, if the host is on, we'd like them to be pushed
immediately, ideally with error codes returned to dbus if the
operation fails.

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

It was proposed we (OpenBMC) add one while back.  I think it muddies
the water of what it means to be a method call, and what it means to
be a property, especially for the use case that it was being proposed
to cover.

>
> 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 think today the behavior is that the network is left in an unusual
state until it's not.  If the config is invalid, and can't be
written(because of depdent properties) we just don't push it down
until it's valid.

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

If you have properties that need to be set in lockstep with one
another to be valid, I suspect that indicates that properties are not
the right tool.  Redfish hits this a lot, where each resource is
expected that any property is modifiable independently, and certain
implementations need an atomic "unit" of update.  bmcweb doesn't want
to have to cache properties that are collectively invalid right now,
but might become valid in the future, so there's an impasse.  Who
keeps the state while it's invalid?  Thus Far, that falls to the
dbus-daemons to store.

In terms of this issue, most (all?) ASIO clients are single threaded,
so I think you have the same dependencies.

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

This tends to be what I've recommended in the past (assuming the
"update" is computationally expensive).  If the update is
computationally "cheap", just go ahead and do it on every transaction.
Ideally PLDM would be modeled such that transactional changes are
"cheap", and don't require a full payload update on every property
change.

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

Dumb question: Does anyone actually need to know the "current" value?
Redfish certainly would need to return  the "pending" value in all
cases, as it's required so the restful API emulates ACID-like
compliance to the user.  Could we just have an optional interface that
indicates "values might not be loaded yet" and simplify the dbus API a
little?

>
> --
> Patrick Williams