<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<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);">
<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">
Partrick/Adriyana/Vijay, Can you please help finalyzing the approach? Based on that we will start the implementation.</div>
<br>
</div>
<div>
<div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
<br>
</div>
<div id="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="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> 21 October 2020 10:57<br>
<b>To:</b> Vijay Khemka <vijaykhemka@fb.com>; Adriana Kobylak <anoo@linux.ibm.com><br>
<b>Cc:</b> patrick@stwcx.xyz <patrick@stwcx.xyz>; 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>; Velumani T-ERS,HCLTech
<velumanit@hcl.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">Hi Vijay,
<div><br>
</div>
<div>As mentioned, the MANIFEST file approach was discussed already. As it is a factory ship-out, it may not be appropriate to add the host IDs into it.</div>
<div><br>
</div>
<div>Partrik was also not inclined towards adding host id into MANIFEST file. Provided below Ptricks response for reference.</div>
<div><br>
</div>
<div>> Why would a MANIFEST file have a different value for a different host</div>
<div>> position anyhow? Isn't the appropriate firmware image for your host</div>
<div>> card dependent on which host-card-hardware you have installed and not</div>
<div>> which position the card is in? The type of hardware should be handled</div>
<div>> by ExtendedVersion</div>
<div><br>
</div>
<div>@Patrick, @Adriana Your comments/suggestion helps.</div>
<div><br>
</div>
<div><br>
</div>
<div>Adriana's below approach could also be considered for implementation. Please suggest.</div>
<div><br>
</div>
<div><br>
</div>
<div>> One thought is to create a property that the user specifies for which</div>
<div>> Host they want to update. This would require creating the</div>
<div>> /xyz/openbmc_project/software/hostX interfaces and the new property when</div>
<div>> the BMC starts up. Then for example:</div>
<div>> - User sets the new "this should be updated" property for host1 and</div>
<div>> host3.</div>
<div>> - User calls the Redfish API and select the bios image to upload.</div>
<div>> - The BMC updater sees it's a host bios image and creates</div>
<div>> hostX/<versionid> interfaces</div>
<div>> - THe BMC updater calls the bios_X updater script for only the host</div>
<div>> instances that have the "this should be updated" property set.</div>
<div><br>
</div>
<div>The image can be deleted after successfully updating all the hosts having "this should be updated" property set.</div>
<div><br>
</div>
<div><br>
</div>
<div>Thanks,</div>
Priyatharshan P<br>
<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> Vijay Khemka <vijaykhemka@fb.com><br>
<b>Sent:</b> 21 October 2020 05:40<br>
<b>To:</b> Adriana Kobylak <anoo@linux.ibm.com>; P. Priyatharshan <PriyatharshanP@hcl.com><br>
<b>Cc:</b> patrick@stwcx.xyz <patrick@stwcx.xyz>; 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>; Velumani T-ERS,HCLTech
<velumanit@hcl.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>
I have another idea of mentioning host details in manifest file to have single<br>
upload only. You can put a single host id or an array of host id in extra version.<br>
Format can be defined, this way as soon as we see bios image uploaded and<br>
based on extra version, it will create as many version interface and allow to<br>
activate them. Once we call all the bios upgrade script, we should delete<br>
image.<br>
<br>
On 10/19/20, 12:26 PM, "Adriana Kobylak" <anoo@linux.ibm.com> wrote:<br>
<br>
Vijay is correct in that today the image file is deleted after a<br>
successful activation. Therefore today's logic will for example delete<br>
the file from /tmp/images/ after Host1 was updated, and a subsequent<br>
request to update Host2 would fail because the image file would not<br>
exist anymore. The reason for deleting the file is to preserve space<br>
since the file is assumed that it's not needed anymore after it was used<br>
for activation. Otherwise we can potentially fill up the /tmp space.<br>
<br>
Let's say we keep the image files around forever in /tmp/images/, next<br>
I'm thinking about the Redfish API where the upload and activation is a<br>
single step, we'd need to figure out how to specify which Host instances<br>
should be updated.<br>
<br>
One thought is to create a property that the user specifies for which<br>
Host they want to update. This would require creating the<br>
/xyz/openbmc_project/software/hostX interfaces and the new property when<br>
the BMC starts up. Then for example:<br>
- User sets the new "this should be updated" property for host1 and<br>
host3.<br>
- User calls the Redfish API and select the bios image to upload.<br>
- The BMC updater sees it's a host bios image and creates<br>
hostX/<versionid> interfaces<br>
- THe BMC updater calls the bios_X updater script for only the host<br>
instances that have the "this should be updated" property set.<br>
<br>
It'd also be good if you could check if Redfish has an ability to<br>
somehow specify the target that needs to be updated, or if others have<br>
implemented this ability in some other way.<br>
<br>
<br>
<br>
On 2020-10-19 12:08, P. Priyatharshan wrote:<br>
> [Vijay's Comment] >Can we use extraversion field in manifest file to<br>
> identify host...<br>
><br>
> This Message Is From an External Sender<br>
><br>
> This message came from outside your organization.<br>
><br>
> [Vijay's Comment]<br>
>> Can we use extraversion field in manifest file to identify host id.<br>
> In manifest file, if purpose is >host then we can check extra version<br>
> and >find out which host it is applicable for.<br>
><br>
> [Priyatharshan Response]<br>
> We have already brought up the point of using manifest file. As a<br>
> response, Patrick mentioned as<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>
> [Vijay's Comment]<br>
>> Or lese we can add another property in /xyz/openbmc_project/software,<br>
><br>
>> name as host id and user can set this property after uploading image.<br>
><br>
>> I don’t agree with creating multiple interfaces for single image<br>
>> upgrade. Because image will be deleted after successful activation.<br>
><br>
> [Priyatharshan Response]<br>
> Your suggestion of adding "host id" property is a good idea, but has<br>
> few caveates<br>
> *. If the image is deleted after programming each host, this brings a<br>
> sequential nature where bios upgrade time prolongs as many times in<br>
> multi-host environment (for ex 16-BladeCenter)<br>
> *. the image needs to be copied into the target every time and the<br>
> upgrades needs to be started. The bios.bin file copy causes additional<br>
> delay in the upgradation<br>
> Based on the approach which we porposed,<br>
> *. with the single bios image, multiple host can be upgraded using<br>
> "RequestActivation" in each interface without deleting the bios image<br>
> *. as it is multi object approach (one for each host), multiple host<br>
> could be programmed concurrently<br>
> This would save bios upgrade time.<br>
><br>
> @Vijay Khemka @patrick@stwcx.xyz @Adriana Kobylak: Kindly share your<br>
> thoughts on this.<br>
><br>
> Thanks,<br>
> Priyatharshan P<br>
><br>
> -------------------------<br>
><br>
> FROM: Vijay Khemka <vijaykhemka@fb.com><br>
> SENT: 16 October 2020 00:58<br>
> TO: P. Priyatharshan <PriyatharshanP@hcl.com>; Adriana Kobylak<br>
> <anoo@linux.ibm.com><br>
> CC: openbmc@lists.ozlabs.org <openbmc@lists.ozlabs.org>;<br>
> anoo@us.ibm.com <anoo@us.ibm.com>; ojayanth@in.ibm.com<br>
> <ojayanth@in.ibm.com>; gmills@linux.vnet.ibm.com<br>
> <gmills@linux.vnet.ibm.com>; Velumani T-ERS,HCLTech<br>
> <velumanit@hcl.com>; ratagupt@linux.vnet.ibm.com<br>
> <ratagupt@linux.vnet.ibm.com><br>
> SUBJECT: Re: Multi host bios upgrade support in<br>
> phosphor-bmc-code-mgmt:<br>
><br>
> [CAUTION: This Email is from outside the Organization. Unless you<br>
> trust the sender, Don’t click links or open attachments as it may be<br>
> a Phishing email, which can steal your Information and compromise your<br>
> Computer.]<br>
><br>
> Can we use extraversion field in manifest file to identify host id.<br>
><br>
> In manifest file, if purpose is host then we can check extra version<br>
><br>
> and find out which host it is applicable for.<br>
><br>
> Or lese we can add another property in /xyz/openbmc_project/software,<br>
><br>
> name as host id and user can set this property after uploading image.<br>
><br>
> I don’t agree with creating multiple interfaces for single image<br>
><br>
> upgrade. Because image will be deleted after successful activation.<br>
><br>
> FROM: openbmc <openbmc-bounces+vijaykhemka=fb.com@lists.ozlabs.org> on<br>
> behalf of "P. Priyatharshan" <PriyatharshanP@hcl.com><br>
> DATE: Thursday, October 15, 2020 at 10:18 AM<br>
> TO: Adriana Kobylak <anoo@linux.ibm.com><br>
> CC: "openbmc@lists.ozlabs.org" <openbmc@lists.ozlabs.org>,<br>
> "anoo@us.ibm.com" <anoo@us.ibm.com>, "ojayanth@in.ibm.com"<br>
> <ojayanth@in.ibm.com>, "gmills@linux.vnet.ibm.com"<br>
> <gmills@linux.vnet.ibm.com>, "Velumani T-ERS, HCLTech"<br>
> <velumanit@hcl.com>, "ratagupt@linux.vnet.ibm.com"<br>
> <ratagupt@linux.vnet.ibm.com><br>
> SUBJECT: Re: Multi host bios upgrade support in<br>
> phosphor-bmc-code-mgmt:<br>
><br>
> Thanks Adriana for the clarification.<br>
><br>
> For host bios update, the images will be copied to BMC(/tmp/images)<br>
> and will start flashing by making RequestedActivation field<br>
> "xyz.openbmc_project.Software.Activation.RequestedActivations.Active".<br>
> In our case, the device location will be same for all the bios images<br>
> (BMC /tmp/images).So I think the above design you proposed[id =<br>
> version+volume ID] may not work effectively for multi host as the id<br>
> is still going to be same for all the hosts.<br>
><br>
> We would like to propose the following approach for your review.Kindly<br>
> go through the below steps and share your valuable suggestions.<br>
><br>
> 1.Number of host will be identified from machine layer<br>
> [OBMC_HOST_INSTANCES]<br>
><br>
> 2.Code will be modified to create n number of objects based on number<br>
> of hosts<br>
><br>
> Ex: Log taken in YosemiteV2 [4 host]<br>
><br>
> root@yosemitev2:~# busctl tree<br>
> xyz.openbmc_project.Software.BMC.Updater<br>
><br>
> `-/xyz<br>
><br>
> `-/xyz/openbmc_project<br>
><br>
> `-/xyz/openbmc_project/software<br>
><br>
> |-/xyz/openbmc_project/software/1929c585<br>
><br>
> |-/xyz/openbmc_project/software/host1<br>
><br>
> | `-/xyz/openbmc_project/software/host1/28bd62d9<br>
><br>
> |-/xyz/openbmc_project/software/host2<br>
><br>
> | `-/xyz/openbmc_project/software/host2/28bd62d9<br>
><br>
> |-/xyz/openbmc_project/software/host3<br>
><br>
> | `-/xyz/openbmc_project/software/host3/28bd62d9<br>
><br>
> `-/xyz/openbmc_project/software/host4<br>
><br>
> `-/xyz/openbmc_project/software/host4/28bd62d9<br>
><br>
> root@yosemitev2:~# busctl tree xyz.openbmc_project.Software.Version<br>
><br>
> `-/xyz<br>
><br>
> `-/xyz/openbmc_project<br>
><br>
> `-/xyz/openbmc_project/software<br>
><br>
> |-/xyz/openbmc_project/software/host1<br>
><br>
> | `-/xyz/openbmc_project/software/host1/28bd62d9<br>
><br>
> |-/xyz/openbmc_project/software/host2<br>
><br>
> | `-/xyz/openbmc_project/software/host2/28bd62d9<br>
><br>
> |-/xyz/openbmc_project/software/host3<br>
><br>
> | `-/xyz/openbmc_project/software/host3/28bd62d9<br>
><br>
> `-/xyz/openbmc_project/software/host4<br>
><br>
> `-/xyz/openbmc_project/software/host4/28bd62d9<br>
><br>
> 3.This will create activation interface for each host. For a<br>
> multi-host system if the RequestedActivation is set to<br>
> "xyz.openbmc_project.Software.Activation.RequestedActivations.Active",<br>
> then different bios service file will be called based the host.<br>
><br>
> For single host : biosServiceFile = "obmc-flash-host-bios@" +<br>
> versionId + ".service";<br>
><br>
> For multi host : biosServiceFile = "obmc-flash-host" + host + "-bios@"<br>
> + versionId + ".service";<br>
><br>
> Then it can be used for multi host even if the firmware image we want<br>
> to install is the same for multiple host targets.<br>
><br>
> I have created a WIP patch for the design proposed above.Kindly have a<br>
> glance and share your comments.<br>
><br>
> <a href="https://apc01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgerrit.openbmc-project.xyz%2Fc%2Fopenbmc%2Fphosphor-bmc-code-mgmt%2F%2B%2F37448&data=04%7C01%7CPriyatharshanP%40hcl.com%7Cef0c97b4694f44db53a508d87555c902%7C189de737c93a4f5a8b686f4ca9941912%7C0%7C0%7C637388358605381286%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=SWOdfla2MDRK4ostBDNzozQBpoyNdyvDNXPMpQo05Tk%3D&reserved=0">
https://apc01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgerrit.openbmc-project.xyz%2Fc%2Fopenbmc%2Fphosphor-bmc-code-mgmt%2F%2B%2F37448&data=04%7C01%7CPriyatharshanP%40hcl.com%7Cef0c97b4694f44db53a508d87555c902%7C189de737c93a4f5a8b686f4ca9941912%7C0%7C0%7C637388358605381286%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=SWOdfla2MDRK4ostBDNzozQBpoyNdyvDNXPMpQo05Tk%3D&reserved=0</a><br>
> [1]<br>
><br>
> Thanks,<br>
><br>
> Priyatharshan P<br>
><br>
> -------------------------<br>
><br>
> FROM: Adriana Kobylak <anoo@linux.ibm.com><br>
> SENT: 06 October 2020 03:11<br>
> TO: P. Priyatharshan <PriyatharshanP@hcl.com><br>
> CC: Patrick Williams <patrick@stwcx.xyz>; Velumani T-ERS,HCLTech<br>
> <velumanit@hcl.com>; openbmc@lists.ozlabs.org<br>
> <openbmc@lists.ozlabs.org>; anoo@us.ibm.com <anoo@us.ibm.com>;<br>
> ojayanth@in.ibm.com <ojayanth@in.ibm.com>; gmills@linux.vnet.ibm.com<br>
> <gmills@linux.vnet.ibm.com>; ratagupt@linux.vnet.ibm.com<br>
> <ratagupt@linux.vnet.ibm.com><br>
> SUBJECT: Re: Multi host bios upgrade support in<br>
> phosphor-bmc-code-mgmt:<br>
><br>
> [CAUTION: This Email is from outside the Organization. Unless you<br>
> trust the sender, Don’t click links or open attachments as it may be<br>
> a Phishing email, which can steal your Information and compromise your<br>
> Computer.]<br>
><br>
> Hi Priyatharshan,<br>
><br>
> > Object : /xyz/openbmc_project/software/[FIRMWARE_VERSION]_[DEVICE]<br>
> > where device could be host1, 2, ...,N<br>
> > Interface : xyz.openbmc_project.Software.Activation<br>
> ><br>
> > Please confirm if our understanding is correct.<br>
><br>
> I meant that to generate the id, which currently uses the version<br>
> string, would instead use the version string plus the string for the<br>
> name of the device where it's stored in order to generate the hash.<br>
> For<br>
> example, today the code calls "SHA512_Update("version")", where<br>
> "version" is for example "2.9.0-dev-663-g2e34bb673". Instead the code<br>
> would detect this version is stored let's say in device "mtd1" or<br>
> "mmcblk0p1", it'd then append that device string to version, ex:<br>
> "2.9.0-dev-663-g2e34bb673-mmcblk0p1" and pass that string to<br>
> SHA512_Update(), therefore creating a different hash depending where<br>
> that version of bmc code is stored.<br>
><br>
> Note that this is for BMC versions only. We discussed that for host<br>
> versions, we'd need to modify the code to add a "os-release" file<br>
> under<br>
> /media/ that contained the host version information similar to the<br>
> BMC's<br>
> os-release file. In addition, we'd need to somehow determine that<br>
> those<br>
> files were for host (Bios) versions instead of BMC ones. Perhaps<br>
> os-release could have an additional field added to specify the<br>
> purpose.<br>
><br>
> > Adriana, Any tentative timeline on your commits availability<br>
> [generate<br>
> > the id based on firmware version plus the device or volume ]<br>
><br>
> I'd say by early next year at the latest.<br>
><br>
> ::DISCLAIMER::<br>
><br>
> -------------------------<br>
><br>
> The contents of this e-mail and any attachment(s) are confidential and<br>
> intended for the named recipient(s) only. E-mail transmission is not<br>
> guaranteed to be secure or error-free as information could be<br>
> intercepted, corrupted, lost, destroyed, arrive late or incomplete, or<br>
> may contain viruses in transmission. The e mail and its contents (with<br>
> or without referred errors) shall therefore not attach any liability<br>
> on the originator or HCL or its affiliates. Views or opinions, if any,<br>
> presented in this email are solely those of the author and may not<br>
> necessarily reflect the views or opinions of HCL or its affiliates.<br>
> Any form of reproduction, dissemination, copying, disclosure,<br>
> modification, distribution and / or publication of this message<br>
> without the prior written consent of authorized representative of HCL<br>
> is strictly prohibited. If you have received this email in error<br>
> please delete it and notify the sender immediately. Before opening any<br>
> email and/or attachments, please check them for viruses and other<br>
> defects.<br>
><br>
> -------------------------<br>
><br>
><br>
> Links:<br>
> ------<br>
> [1]<br>
> <a href="https://apc01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgerrit.openbmc-project.xyz%2Fc%2Fopenbmc%2Fphosphor-bmc-code-mgmt%2F%2B%2F37448&data=04%7C01%7CPriyatharshanP%40hcl.com%7Cef0c97b4694f44db53a508d87555c902%7C189de737c93a4f5a8b686f4ca9941912%7C0%7C0%7C637388358605381286%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=SWOdfla2MDRK4ostBDNzozQBpoyNdyvDNXPMpQo05Tk%3D&reserved=0">
https://apc01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgerrit.openbmc-project.xyz%2Fc%2Fopenbmc%2Fphosphor-bmc-code-mgmt%2F%2B%2F37448&data=04%7C01%7CPriyatharshanP%40hcl.com%7Cef0c97b4694f44db53a508d87555c902%7C189de737c93a4f5a8b686f4ca9941912%7C0%7C0%7C637388358605381286%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=SWOdfla2MDRK4ostBDNzozQBpoyNdyvDNXPMpQo05Tk%3D&reserved=0</a><br>
<br>
</div>
</span></font></div>
</div>
</body>
</html>