<html>
<head>
<meta http-equiv="Content-Type" content="text/html;
charset=windows-1252">
</head>
<body>
<p>Hi All,</p>
<p>Adding one more problem here with settings infra and with some
proposed solutions.<br>
</p>
<p>Problem Domain:</p>
<p> - With multi property update from redfish , webserver
updates the settings object<br>
- PLDM on bmc listens on the property update of settings
object and notifies to Hypervisor<br>
- As there can be multiple properties in single PATCH
operation, PLDM on bmc sends<br>
multiple Notifications to Hypervisor<br>
- Specifically in case of network config, single property
update on phyp may lead to network inconsistency.<br>
<br>
How can we solve this?</p>
<ul>
<li>Proposal 1: Add one more property in the settings Dbus object
itself which tells that it is ready to be read, PLDM on the BMC
watching on that property and read the whole network
configuration and notifies Hypervisor.</li>
</ul>
<ul>
<li>Proposal 2: Hypervisor runs the timer if the bios attr belongs
to network configuration and once the timer expires,it reads the
bios attr related to network and applies it.</li>
</ul>
<ul>
<li>Proposal 3: Add one more bios attribute in the bios table
which tells that Bios configuration can be read and applied by
the Hypervisor for the network configuration. <br>
</li>
</ul>
<p><br>
Looking for suggestion what could be the best way here?<br>
</p>
<p>Ratan</p>
<div class="moz-cite-prefix">On 9/19/20 11:11 AM, Ratan Gupta wrote:<br>
</div>
<blockquote type="cite"
cite="mid:c007630e-54e2-df13-e6da-0af0b2998279@linux.vnet.ibm.com">
<br>
On 9/17/20 9:06 PM, Patrick Williams wrote:
<br>
<blockquote type="cite">On Thu, Sep 17, 2020 at 01:10:06PM +0530,
Ratan Gupta wrote:
<br>
<blockquote type="cite">We need to address the below two
concerns with the existing settings infra.
<br>
</blockquote>
Both of these seem like missing features based on our now
greater
<br>
understanding of the problem domain from where we were 3-4 years
ago
<br>
when phosphor-settings-manager was originally written, right?
That
<br>
doesn't seem like a good reason to entirely throw out the
approach.
<br>
<br>
<blockquote type="cite"> * Pending v/s configured value:
Currently settings have single Dbus
<br>
Object, Some properties which is for host firmware we
need to have
<br>
two placeholders one for Pending values and one for
Configured
<br>
values. Bios settings have this concept.
<br>
o Should we add two Dbus objects in settings infra?
<br>
</blockquote>
This was going to be my suggestion, yes. You could have two
sets of the
<br>
objects: current and pending. 'current' objects may not be
written by
<br>
dbus-clients. These are the same terms used by the BIOSConfig
proposal.
<br>
</blockquote>
Thanks Patrick, seems reasonable to have two D-bus objects.
<br>
<blockquote type="cite">
<br>
What I am not seeing in BIOSConfig and is equally applicable
here is
<br>
_when_ pending is applied to current. You will need some
interface that
<br>
IPMI / PLDM can call to apply those settings? Or, do you
monitor host
<br>
state signals automatically?
<br>
<br>
<blockquote type="cite"> * Dynamic Dbus objects: Currently
settings infrastructure is only for
<br>
static objects, Objects which gets added on runtime,
settings infra
<br>
doesn't support that.
<br>
o Eg: IP address on ethernet interface is dynamic in
nature, An
<br>
ethernet interface can have multiple IP address on
it.
<br>
considering if SLAAC is enabled(ipV6).
<br>
o Seems this problem is common for both(settings v/s
bios-settings)
<br>
</blockquote>
I assume these would be requested for creation by IPMI / PLDM?
We could
<br>
use a similar model to xyz.openbmc_project.Inventory.Manager
where
<br>
objects are requested for creation dynamically through a method.
<br>
</blockquote>
We don't have this requirement now but in near future it is going
to
<br>
be there, we can improve the settings infra to support this.
<br>
<blockquote type="cite">
<br>
</blockquote>
</blockquote>
</body>
</html>