Using bios-settings-mgr for setting hypervisor network attributes

[Ed Tanous]

On Wed, Sep 30, 2020 at 8:05 AM Ratan Gupta <ratagupt at linux.vnet.ibm.com> wrote:
>
> Thanks all for providing the suggestions
>
> Currently Redfish Ethernet interface is not having the concept of
> pending and configured values,That means if we use the EthernetInterface
> schema, User can only see the configured values, There is no way through
> which user can see the pending value, We need to come up with some REST
> API to show the pending values.
>
> To solve this problem, Redfish has bios schema whch has the pending
> attributes as well as the configured attributes

Did not realize that about the Redfish schema.  Sounds like we need both then.

>
> How about using the Redfish Bios schema for front end and Bios-settings
> manager as backend to make the things simpler?

I'm not quite following.  Are you saying put the pending settings in
the webserver?

>
> Ratan
>
> On 9/24/20 9:06 PM, Ed Tanous wrote:
> > On Wed, Sep 23, 2020 at 2:26 PM Patrick Williams <patrick at stwcx.xyz> wrote:
> >> On Wed, Sep 23, 2020 at 01:51:33PM -0700, Ed Tanous wrote:
> >>> 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:
> >>>>
> >>>> 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.
> >> I'm not sure why it would be considered mudding the water.  All property
> >> Get/Set/GetAll operations really are just a method call under the covers
> >> anyhow to org.freedesktop.DBus.Properties.  I do think that ideally we'd
> >> get the method added directly to that interface because then the DBus
> >> bindings will support it natively.
> > Mudding the water of when to use a property, versus when to use a
> > method call (yes, properties are method calls underneath).  If there's
> > a method call, the dependency between the parameters is documented in
> > the interface, with a SetProperties method call, it isn't, and you
> > have to rely on just knowing, or it being implementation defined.  In
> > those cases, I'd much rather the itnerface make the jump straight to a
> > method call, and skip properties entirely.
> >
> >> I forgot the mention this again, but another way to solve it is similar
> >> to xyz.openbmc_project.Inventory.Manager where you take a fully (or
> >> partially) formed object as a method parameter and the process which
> >> hosts Inventory.Manager hosts the object.  Settings could be done the
> >> same way.  The issue is, again, having other processes know when to use
> >> this new method and when to just update properties.
> > This tends to be the pattern we use.  My usual take on it when I see a
> > new interface is, if the create method exists, use it.
> >
> >>>> 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.
> >> Agreed.  This has also been a general statement  we've made in reviews
> >> for new interfaces.  "If you need to update multiple properties, use
> >> a method; if you are just updating a single property, update the property."
> > +1
> >
> >>>> 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?
> >> I think this is generally for humans in the case of BIOS settings.
> >>     - "What is the setting my system is currently running with?"
> >>     - "What will happen next time I reboot?"
> > I wonder if we could make a logging API for humans to use, and keep
> > the "present" things off dbus.  It seems like it would simplify the
> > implementation quite a bit. <thinking out loud a little>
> >
> >> I don't know how this is modeled in Redfish.
> >>
> >> --
> >> Patrick Williams