Using bios-settings-mgr for setting hypervisor network attributes

[Deepak Kodihalli]

On 17/09/20 1:10 pm, Ratan Gupta wrote:
> Hi Pattrick, Ed, We need to address the below two concerns with the 
> existing...
> This Message Is From an External Sender
> This message came from outside your organization.
> 
> Hi Pattrick, Ed,
> 
> 
> We need to address the below two concerns with the existing settings infra.
> 
>   * Pending v/s configured value: Currently settings have single Dbus
>     Object, Some properties which is for host firmware we need to have
>     two placeholders one for Pending values and one for Configured
>     values. Bios settings have this concept.
>       o Should we add two Dbus objects in settings infra?
>   * Dynamic Dbus objects: Currently settings infrastructure is only for
>     static objects, Objects which gets added on runtime, settings infra
>     doesn't support that.
>       o Eg: IP address on ethernet interface is dynamic in nature, An
>         ethernet interface can have multiple IP address on it.
>         considering if SLAAC is enabled(ipV6).
>       o Seems this problem is common for both(settings v/s bios-settings)

+1. The settings daemon doesn't offer all the functionality expected to 
work with BIOS attributes. For that reason, if there are a class of 
attributes which are updated out of band via non-BIOS Redfish schema, 
but these are sent up to the host as updated BIOS attributes, the 
bios-settings-mgr app seems to be a better fit.

Thanks,
Deepak

> Regards
> Ratan Gupta
> 
> 
> On 9/16/20 11:14 PM, Ed Tanous wrote:
>> On Wed, Sep 16, 2020 at 10:20 AM Patrick Williams<patrick at stwcx.xyz>  wrote:
>>> On Wed, Sep 16, 2020 at 08:17:01PM +0530, manoj kiran wrote:
>>>> Hi Ed & James,
>>>>
>>>> Till now IBM was using phosphor-settings infrastructure as back-end and uses Ethernet Schema for Hypervisor computer system(hypervisor_ethernet.hpp) for setting the IP address of hypervisor. And now we are planning to leverage the capabilities of bios-settings-mgr(backend) as well to set the hypervisor attributes.
>>>> do you see any concerns here ?
>>>> Thanks,
>>>> Manoj
>>> These end up being two quite different implementations from a dbus
>>> perspective, which could have implications to Redfish and webui users.
>>>
>>> With 'settings' there is no generic settings interfacess on dbus; every
>>> setting is required to have some modeled interface.  This is great when
>>> you are exposing some hypervisor setting that the BMC also has for
>>> itself, such as network.  We have a single dbus interface for all
>>> network end-points and it doesn't matter if it is for the BMC or the
>>> Hypervisor.
>>>
>>> With 'bios-settings-mgr' there are only generic free-form settings
>>> values, which presently can be either int64 or string[1].
>> If this is correct, then I withdraw my support.  I had assumed
>> bios-settings-mgr would host several objects that contain an
>> EthernetInterface [1] api, similar to what phosphor-networkd does, and
>> whose endpoints require no new code in most of the endpoints.  If
>> we're talking about moving all this to a simple key-value store,
>> running on yet another representation of what a network interface
>> looks like, that's going in the wrong direction in terms of fidelity
>> and complexity.
>>
>> With that said, if I'm mistaken, let me know.
>>
>>>   This means
>>> there is no overlap with any similar settings we have on the BMC and
>>> there is no programatic way to ensure the data is of the right type and
>>> named with the right key.  This approach is better when you have large
>>> numbers of attributes for concepts which the BMC doesn't have itself.
>>>
>>> My understanding was that the 'bios-settings-mgr' was typically going to be
>>> used for uploading a large blob of configuration values and the external
>>> interfaces would have fairly minimal code related to individual
>>> settings.  My concern with using 'bios-settings-mgr' in general is that
>>> it will end up being very tight coupling between external interfaces
>>> (Redfish / webui) and BIOS implementations.  When you use 'settings',
>>> you can implement much more generic external interface code and likely
>>> limit the coupling, if any, to the PLDM provider.
>> I think we have one benefit here in that there's going to be several
>> implementations of the bios-settings-mgr for the various bios
>> implementations that will keep us more "honest" about our APIs.  It's
>> not a satisfying answer, I realize, but I think it's the best we can
>> do at the moment.
>>
>>> Net is, if you're expecting to be able to modify hypervisor values
>>> through Redfish or WebUI, I think the best approach is to use
>>> 'settings'.
>> The problem with the "settings" approach becomes error handling.
>> Settingsd has no context of a transaction, or a backend on the other
>> side, so when and if things fail, they fail silently, or possibly with
>> a log.  In the case of hosting this API in the BIOS daemon, it can
>> actually do the "commit" of the parameters to BIOS as part of the dbus
>> transaction, so once the return code is received from the method call,
>> the user can know that the values were "latched", and can knowingly
>> move on.  If they weren't latched, the client can know if it makes
>> sense to retry, or do some other procedure.
>> This also has nice properties for the BMC, as it never has to "own"
>> storage of the data, nor does it have to implement all the validation
>> routines, as it can rely on the actual data owner to do so.
>>
>>> 1.https://github.com/openbmc/phosphor-dbus-interfaces/blob/77a742627edde54aec625d7c1a200d9f4832f0ba/xyz/openbmc_project/BIOSConfig/Manager.interface.yaml#L44
>>>
>>> --
>>> Patrick Williams
>> 1.https://github.com/openbmc/phosphor-dbus-interfaces/blob/master/xyz/openbmc_project/Network/EthernetInterface.interface.yaml