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 wrote: > >> On 9/30/20 9:26 PM, Ed Tanous wrote: >> >>> On Wed, Sep 30, 2020 at 8:05 AM Ratan Gupta >>> 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 >>>>> 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 >>>>>>> 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. >>>>> >>>>> >>>>> >>>>>> I don't know how this is modeled in Redfish. >>>>>> >>>>>> -- >>>>>> Patrick Williams >>>>>>