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