Using bios-settings-mgr for setting hypervisor network attributes

Ratan Gupta ratagupt at linux.vnet.ibm.com
Tue Oct 20 21:43:49 AEDT 2020 

Hi Ed,Pattrick

Thanks for your suggestions,

Any choice with the below two proposals?

1/

How about using the Redfish Bios schema for redfish data modeling and Bios-settings
manager as backend to make the things simpler?

https://gerrit.openbmc-project.xyz/c/openbmc/bmcweb/+/29670
https://gerrit.openbmc-project.xyz/c/openbmc/bios-settings-mgr/+/35563

                                   *or*

2/

Redfish EthernetSchema at redfish data modelling and phosphor-settings at backend(D-bus object)
                                      +

Some code which writes the data from settings Dbus object to bios-settings as PLDM is having infra to read from the BIOS-Settings table and send the bios table to Hypervisor.

NOTE: In the later case we don't have way in redfish to show the pending values.we can only show the configured values.

Ratan


On 10/16/20 5:10 PM, manoj kiran wrote:
> Hi Ed/Ratan,
>
> Just bumping this thread again to see if we can get to a conclusion on
> this problem.
>
> Thanks,
> Manoj
>
> On Oct 1 2020, at 4:47 pm, Ratan Gupta <ratagupt at linux.vnet.ibm.com> wrote:
>
>> On 9/30/20 9:26 PM, Ed Tanous wrote:
>>
>>> 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.
>> https://redfish.dmtf.org/schemas/v1/Bios.v1_1_1.json
>>
>> The Bios schema contains properties related to the BIOS attribute
>> registry. The attribute registry describes the system-specific BIOS
>> attributes and actions for changing to BIOS settings. Changes to the
>> BIOS typically require a system reset before they take effect. It is
>> likely that a client finds the `@Redfish.Settings` term in this
>> resource, and if it is found, the client makes requests to change BIOS
>> settings by modifying the resource identified by the
>> `@Redfish.Settings` term."
>>
>>
>>>
>>>> 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?
>>>
>> No, I was mentioning that instead of using the EthernetInterface
>> schema , Can we use theBios schema for the network configuration and
>> this bios schema is backed up with bios-settings manager D-bus Repo.
>>
>> https://gerrit.openbmc-project.xyz/c/openbmc/bmcweb/+/29670
>>
>> https://gerrit.openbmc-project.xyz/c/openbmc/bios-settings-mgr/+/35563
>>
>>
>>>
>>>> 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
>>>>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ozlabs.org/pipermail/openbmc/attachments/20201020/4db6ac84/attachment-0001.htm>

More information about the openbmc mailing list