Re: Using bios-settings-mgr for setting hypervisor network attributes

[Ratan Gupta <ratagupt@linux.vnet.ibm.com>]

[-- Attachment #1: Type: text/plain, Size: 7234 bytes --]

On 9/30/20 9:26 PM, Ed Tanous wrote:
> On Wed, Sep 30, 2020 at 8:05 AM Ratan Gupta <ratagupt@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@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@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

[-- Attachment #2: Type: text/html, Size: 10433 bytes --]