<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=Windows-1252">
<style type="text/css" style="display:none;"> P {margin-top:0;margin-bottom:0;} </style>
</head>
<body dir="ltr">
<div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
<br>
</div>
<div><font size="2"><span style="font-size:11pt"><b>Adriana</b> : The phosphor-bmc-code-mgmt repo manages out-of-band updates. Maybe the<br>
IPMI flash repo[2] is relevant here? It has tools to do an inband update<br>
through IPMI to the bmc and host.</span></font></div>
<div><font size="2"><span style="font-size:11pt"><br>
</span></font></div>
<div><font size="2"><span style="font-size:11pt"><b>Priyatharshan</b> : Thanks for the info.. It seems IPMI-flash repo does not suit our requirements as it provides support only for IPMI not for IPMB.</span></font><br>
<font size="2"><span style="font-size:11pt"></span></font></div>
<div><font size="2"><span style="font-size:11pt"><br>
</span></font></div>
<div><font size="2"><span style="font-size:11pt">Adriana, Any tentative timeline on your commits availability [generate the id based on firmware version plus the device or volume ]<br>
</span></font></div>
<div><font size="2"><span style="font-size:11pt"><br>
</span></font></div>
<div><font size="2"><span style="font-size:11pt">Thanks,</span></font></div>
<div><font size="2"><span style="font-size:11pt">Priyatharshan P<br>
</span></font>
<div id="Signature">
<div>
<div style="font-family:Calibri,Arial,Helvetica,sans-serif; font-size:12pt; color:rgb(0,0,0)">
</div>
</div>
</div>
</div>
<div id="appendonsend"></div>
<hr style="display:inline-block;width:98%" tabindex="-1">
<div id="divRplyFwdMsg" dir="ltr"><font face="Calibri, sans-serif" style="font-size:11pt" color="#000000"><b>From:</b> P. Priyatharshan <PriyatharshanP@hcl.com><br>
<b>Sent:</b> 01 October 2020 21:22<br>
<b>To:</b> Adriana Kobylak <anoo@linux.ibm.com>; Patrick Williams <patrick@stwcx.xyz><br>
<b>Cc:</b> Velumani T-ERS,HCLTech <velumanit@hcl.com>; openbmc@lists.ozlabs.org <openbmc@lists.ozlabs.org>; anoo@us.ibm.com <anoo@us.ibm.com>; ojayanth@in.ibm.com <ojayanth@in.ibm.com>; gmills@linux.vnet.ibm.com <gmills@linux.vnet.ibm.com>; ratagupt@linux.vnet.ibm.com
<ratagupt@linux.vnet.ibm.com><br>
<b>Subject:</b> Re: Multi host bios upgrade support in phosphor-bmc-code-mgmt:</font>
<div> </div>
</div>
<style type="text/css" style="display:none">
<!--
p
{margin-top:0;
margin-bottom:0}
-->
</style>
<div dir="ltr">
<div>
<div style="font-family:Calibri,Arial,Helvetica,sans-serif; font-size:12pt; color:rgb(0,0,0)">
<div style="box-sizing:border-box; font-family:"Segoe UI",system-ui,"Apple Color Emoji","Segoe UI Emoji",sans-serif; font-size:14px; orphans:2; widows:2">
<div>Adrina/Patrick,</div>
<div><br>
</div>
<div>Thanks for your comments. Sorry for the late reply, i was on paternity leave for a week.</div>
<div>
<div> </div>
<div>Adriana,</div>
<div>We understand that your changes for multi host (generate the id based on firmware version plus the device or volume) will look like</div>
<div> </div>
<div>
<div>
<div>
<div>For single host (existing implementation will not be modified) and mentioned below,</div>
<div>
<div> Dbus : xyz.openbmc_project.Software.BMC.Updater<br>
Object : /xyz/openbmc_project/software/<b>[firmware_version]</b><br>
Interface : xyz.openbmc_project.Software.Activation</div>
<div>
<div>
<div> </div>
<div>
<div>For multi host with same firmware version id generation changes,</div>
<div>
<div>
<div> Dbus : xyz.openbmc_project.Software.BMC.Updater</div>
<div>
<div> Object : /xyz/openbmc_project/software/<b>[firmware_version]_[device]</b> where device could be host1, 2, ...,N<br>
Interface : xyz.openbmc_project.Software.Activation</div>
<div>
<div>
<div> </div>
<div>We also expect that the interface (xyz.openbmc_project.Software.Activation) will be created for each object (/xyz/openbmc_project/software/[firmware_version]_[device])</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
<br>
</div>
<div style="font-family:Calibri,Arial,Helvetica,sans-serif; font-size:12pt; color:rgb(0,0,0)">
<div style="box-sizing:border-box; font-family:"Segoe UI",system-ui,"Apple Color Emoji","Segoe UI Emoji",sans-serif; font-size:14px; orphans:2; widows:2">
Please confirm if our understanding is correct. </div>
<br>
</div>
<div id="x_Signature">
<div>
<div style="font-family:Calibri,Arial,Helvetica,sans-serif; font-size:12pt; color:rgb(0,0,0)">
Thanks,</div>
<div style="font-family:Calibri,Arial,Helvetica,sans-serif; font-size:12pt; color:rgb(0,0,0)">
Priyatharshan P</div>
</div>
</div>
</div>
<div id="x_appendonsend"></div>
<hr tabindex="-1" style="display:inline-block; width:98%">
<div id="x_divRplyFwdMsg" dir="ltr"><font face="Calibri, sans-serif" color="#000000" style="font-size:11pt"><b>From:</b> Adriana Kobylak <anoo@linux.ibm.com><br>
<b>Sent:</b> 22 September 2020 02:28<br>
<b>To:</b> Patrick Williams <patrick@stwcx.xyz><br>
<b>Cc:</b> P. Priyatharshan <PriyatharshanP@hcl.com>; Sundaramoorthy Thiyagarajan <sundaramoorthyt@hcl.com>; Velumani T-ERS,HCLTech <velumanit@hcl.com>; openbmc@lists.ozlabs.org <openbmc@lists.ozlabs.org>; anoo@us.ibm.com <anoo@us.ibm.com>; ojayanth@in.ibm.com
<ojayanth@in.ibm.com>; gmills@linux.vnet.ibm.com <gmills@linux.vnet.ibm.com>; ratagupt@linux.vnet.ibm.com <ratagupt@linux.vnet.ibm.com><br>
<b>Subject:</b> Re: Multi host bios upgrade support in phosphor-bmc-code-mgmt:</font>
<div> </div>
</div>
<div class="x_BodyFragment"><font size="2"><span style="font-size:11pt">
<div class="x_PlainText">[CAUTION: This Email is from outside the Organization. Unless you trust the sender, Don’t click links or open attachments as it may be a Phishing email, which can steal your Information and compromise your Computer.]<br>
<br>
On 2020-09-21 14:46, Patrick Williams wrote:<br>
> On Mon, Sep 21, 2020 at 05:49:14PM +0000, P. Priyatharshan wrote:<br>
>><br>
>> Hi ,<br>
>><br>
>> Phosphor-software-manager currently supports bios upgrade for a single<br>
>> host.I would like to propose a design to add multi host bios upgrade<br>
>> support in Phosphor-software-manager.<br>
>><br>
>> Kindly review the below proposal and share your valuable comments.<br>
>><br>
>> Design:<br>
>><br>
>> a) : Add Host Number<br>
>><br>
>> 1) MANIFEST file change:<br>
>><br>
>> Add host number in MANIFEST file, purpose field like below.<br>
>><br>
>> Ex:<br>
>> For Host1,<br>
>> purpose=xyz.openbmc_project.Software.Version.VersionPurpose.Host1<br>
>> For Host2,<br>
>> purpose=xyz.openbmc_project.Software.Version.VersionPurpose.Host2 and<br>
>> So on.<br>
><br>
> These 'purpose' values align with the Purpose field in Software.Version<br>
> (and the VersionPurpose enumeration). We really don't want to add Host<br>
> positions to this enumeration set.<br>
><br>
> Why would a MANIFEST file have a different value for a different host<br>
> position anyhow? Isn't the appropriate firmware image for your host<br>
> card dependent on which host-card-hardware you have installed and not<br>
> which position the card is in? The type of hardware should be handled<br>
> by ExtendedVersion.<br>
><br>
> I can't imagine that a 16-blade BladeCenter would want to have 16<br>
> different files for each slot in the BladeCenter. That doesn't sound<br>
> like a great user experience.<br>
><br>
>> 2) For bios upgrade, handle the same to incorporate the host number<br>
>> and send host number to the systemd service<br>
>> obmc-flash-host-bios@service like below.<br>
>><br>
>> if (host.empty())<br>
>> {<br>
>> auto biosServiceFile = "obmc-flash-host-bios@" + versionId +<br>
>> ".service";<br>
>> }<br>
>> else<br>
>> {<br>
>> auto biosServiceFile =<br>
>> "obmc-flash-host-bios@" + versionId + "_" + host +<br>
>> ".service";<br>
>> }<br>
><br>
> It doesn't seem like systemd had a clear mechanism to create a<br>
> 'multi-parameter template' which seems to be what you're asking for.<br>
> We<br>
> should probably define a convention for openbmc. I'm somewhat<br>
> surprised<br>
> that versionId is part of the template parameters to begin with.<br>
><br>
> I think there is a question you've missed (assuming we're not using the<br>
> purpose field to identify which host): How do we handle activation for<br>
> firmware images which can apply to multiple entities? Today, as best I<br>
> can tell, there is a 1:1 mapping between firmware images and inventory<br>
> items they apply on. At least, this is the case in<br>
> phosphor-bmc-code-mgmt, which is where this code you linked to is.<br>
><br>
> Reading the section "ItemUpdater" at [1], it seems that we can have<br>
> multiple Activation interfaces for a single Software version and these<br>
> Activation interfaces are expected to be associated to the<br>
> Inventory.Item they manage. This would mean that we should create <N><br>
> activation objects, one for each host, and modifying<br>
> `RequestedActivation` will activate only for that host.<br>
><br>
> (Adriana can maybe weight in here?)<br>
<br>
Agree with what Patrick has said.<br>
One current limitation is the version id is generated from the firmware<br>
version string, meaning that it can't be duplicate d-bus interfaces with<br>
the same version id.<br>
One feature that I think will help with this multi-host scenario is that<br>
I'll be pushing up a change for review to generate the id based on<br>
firmware version plus the device or volume where the firmware version<br>
resides, thus allowing different multiple interfaces with the same<br>
firmware version. The use-case is to allow BMCs that support two<br>
firmware versions to have the same firmware on both sides.<br>
This can then be used for multi-host by creating an Activation interface<br>
for each host even if the firmware image we want to install is the same<br>
for multiple host targets, by using some unique identifier for each host<br>
instance to generate the id.<br>
<br>
><br>
>><br>
>> b) : Implement a generic IPMI based multi-host bios upgrade.<br>
>><br>
>> 1) This generic implementation expects a json config file with the<br>
>> details like IPMI net function , command id, and etc and process the<br>
>> bios upgrade via ipmi commands.<br>
><br>
> I'm not following how this is related unless this is the code inside<br>
> 'obmc-flash-host-bios@'? You're not expecting this IPMI function to<br>
> dynamically create your MANIFEST, are you? MANIFEST files need to be<br>
> digitally signed when you're doing secure updates, so you cannot<br>
> dynamically manipulate them.<br>
><br>
<br>
The phosphor-bmc-code-mgmt repo manages out-of-band updates. Maybe the<br>
IPMI flash repo[2] is relevant here? It has tools to do an inband update<br>
through IPMI to the bmc and host.<br>
<br>
><br>
> 1.<br>
> <a href="https://apc01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fopenbmc%2Fphosphor-dbus-interfaces%2Ftree%2Fmaster%2Fxyz%2Fopenbmc_project%2FSoftware%23itemupdater&data=02%7C01%7CPriyatharshanP%40hcl.com%7C230241680e504b3d447208d85e711c33%7C189de737c93a4f5a8b686f4ca9941912%7C0%7C0%7C637363187181175557&sdata=4sGybP9lK0Xjuyds9rlyjuRtY8%2FY%2F6qMkDFP0hDhwaY%3D&reserved=0">
https://apc01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fopenbmc%2Fphosphor-dbus-interfaces%2Ftree%2Fmaster%2Fxyz%2Fopenbmc_project%2FSoftware%23itemupdater&data=02%7C01%7CPriyatharshanP%40hcl.com%7C230241680e504b3d447208d85e711c33%7C189de737c93a4f5a8b686f4ca9941912%7C0%7C0%7C637363187181175557&sdata=4sGybP9lK0Xjuyds9rlyjuRtY8%2FY%2F6qMkDFP0hDhwaY%3D&reserved=0</a><br>
<br>
2. <a href="https://apc01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fopenbmc%2Fphosphor-ipmi-flash&data=02%7C01%7CPriyatharshanP%40hcl.com%7C230241680e504b3d447208d85e711c33%7C189de737c93a4f5a8b686f4ca9941912%7C0%7C0%7C637363187181175557&sdata=yF2JTBCD6D2SAPcucHBQuiUnSeOxnpI%2BOx37yjAJylU%3D&reserved=0">
https://apc01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fopenbmc%2Fphosphor-ipmi-flash&data=02%7C01%7CPriyatharshanP%40hcl.com%7C230241680e504b3d447208d85e711c33%7C189de737c93a4f5a8b686f4ca9941912%7C0%7C0%7C637363187181175557&sdata=yF2JTBCD6D2SAPcucHBQuiUnSeOxnpI%2BOx37yjAJylU%3D&reserved=0</a><br>
</div>
</span></font></div>
</div>
<font face="Arial" color="Gray" size="1">::DISCLAIMER::<br>
<hr>
The contents of this e-mail and any attachment(s) are confidential and intended for the named recipient(s) only. E-mail transmission is not guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or
incomplete, or may contain viruses in transmission. The e mail and its contents (with or without referred errors) shall therefore not attach any liability on the originator or HCL or its affiliates. Views or opinions, if any, presented in this email are solely
those of the author and may not necessarily reflect the views or opinions of HCL or its affiliates. Any form of reproduction, dissemination, copying, disclosure, modification, distribution and / or publication of this message without the prior written consent
of authorized representative of HCL is strictly prohibited. If you have received this email in error please delete it and notify the sender immediately. Before opening any email and/or attachments, please check them for viruses and other defects.<br>
<hr>
</font>
</body>
</html>