openbmc.lists.ozlabs.org archive mirror
 help / color / mirror / Atom feed
From: Patrick Williams <patrick@stwcx.xyz>
To: manoj kiran <manojkiran.eda@gmail.com>
Cc: "ed@tanous.net" <ed@tanous.net>,
	"james.feist@linux.intel.com" <james.feist@linux.intel.com>,
	"openbmc@lists.ozlabs.org" <openbmc@lists.ozlabs.org>
Subject: Re: Using bios-settings-mgr for setting hypervisor network attributes
Date: Wed, 16 Sep 2020 12:20:45 -0500	[thread overview]
Message-ID: <20200916172045.GD6152@heinlein> (raw)
In-Reply-To: <C9C88F03-4715-444E-9B1A-3834995458EA@getmailspring.com>

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

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].  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.

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'.

1. https://github.com/openbmc/phosphor-dbus-interfaces/blob/77a742627edde54aec625d7c1a200d9f4832f0ba/xyz/openbmc_project/BIOSConfig/Manager.interface.yaml#L44

-- 
Patrick Williams

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

  parent reply	other threads:[~2020-09-17  0:41 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-09-16 14:47 Using bios-settings-mgr for setting hypervisor network attributes manoj kiran
2020-09-16 16:26 ` Ed Tanous
2020-09-16 16:33   ` James Feist
2020-09-16 17:20 ` Patrick Williams [this message]
2020-09-16 17:44   ` Ed Tanous
2020-09-17  7:40     ` Ratan Gupta
2020-09-17 12:21       ` Deepak Kodihalli
2020-09-17 14:20       ` Thomaiyar, Richard Marian
2020-09-17 15:36       ` Patrick Williams
2020-09-19  5:41         ` Ratan Gupta
2020-09-22  9:09           ` Ratan Gupta
2020-09-22 12:08             ` Deepak Kodihalli
2020-11-05 16:48               ` Brad Bishop
2020-09-23 19:24             ` Patrick Williams
2020-09-23 20:51               ` Ed Tanous
2020-09-23 21:26                 ` Patrick Williams
2020-09-24 13:08                   ` Deepak Kodihalli
2020-09-24 15:36                   ` Ed Tanous
2020-09-30 15:05                     ` Ratan Gupta
2020-09-30 15:56                       ` Ed Tanous
2020-10-01 11:17                         ` Ratan Gupta
2020-10-16 11:40                           ` manoj kiran
2020-10-20 10:43                             ` Ratan Gupta
2020-09-24  7:30               ` Ratan Gupta

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20200916172045.GD6152@heinlein \
    --to=patrick@stwcx.xyz \
    --cc=ed@tanous.net \
    --cc=james.feist@linux.intel.com \
    --cc=manojkiran.eda@gmail.com \
    --cc=openbmc@lists.ozlabs.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).