Thanks,<= /div>

Priyatharshan P

From: P. Priyatharshan <= PriyatharshanP@hcl.com>
Sent: 01 October 2020 21:22
To: Adriana Kobylak <anoo@linux.ibm.com>; Patrick Williams <= ;patrick@stwcx.xyz>
Cc: Velumani T-ERS,HCLTech <velumanit@hcl.com>; openbmc@lists.= ozlabs.org <openbmc@lists.ozlabs.org>; anoo@us.ibm.com <anoo@us.ib= m.com>; ojayanth@in.ibm.com <ojayanth@in.ibm.com>; gmills@linux.vn= et.ibm.com <gmills@linux.vnet.ibm.com>; ratagupt@linux.vnet.ibm.com <ratagupt@linux.vnet.ibm.com>
Subject: Re: Multi host bios upgrade support in phosphor-bmc-code-mg= mt:

Adrina/Patrick,

Thanks for your comments. Sorry for the late reply, i was on paternity= leave for a week.

Adriana,

We understand that your changes for multi host (generate the id based = on firmware version plus the device or volume) will look like

For single host (existing implementation will not be modified) and men= tioned below,

Dbus : xyz.openbmc_proj= ect.Software.BMC.Updater
Object : /xyz/openbmc_project/softw= are/[firmware_version]
Interface : xyz.openbmc_project.Software.Activat= ion

For multi host with same firmware version id generation changes,

Dbus : xyz.openbmc_pro= ject.Software.BMC.Updater

Object : /xyz/openbmc_project= /software/[firmware_version]_[device] wher= e device could be host1, 2, ...,N
Interface : xyz.openbmc_project.Software.Activa= tion

We also expect that the interface (xyz.openbmc_project.Software.Activa= tion) will be created for each object (/xyz/openbmc_project/software/[firmw= are_version]_[device])

Please confirm if our understanding is correct.

Thanks,

Priyatharshan P

From: Adriana Kobylak <= ;anoo@linux.ibm.com>
Sent: 22 September 2020 02:28
To: Patrick Williams <patrick@stwcx.xyz>
Cc: P. Priyatharshan <PriyatharshanP@hcl.com>; Sundaramoorthy = Thiyagarajan <sundaramoorthyt@hcl.com>; Velumani T-ERS,HCLTech <ve= lumanit@hcl.com>; openbmc@lists.ozlabs.org <openbmc@lists.ozlabs.org&= gt;; anoo@us.ibm.com <anoo@us.ibm.com>; ojayanth@in.ibm.com <ojayanth@in.ibm.com>; gmills@linux.vnet.ibm.com <gmills@linux.vn= et.ibm.com>; ratagupt@linux.vnet.ibm.com <ratagupt@linux.vnet.ibm.com= >
Subject: Re: Multi host bios upgrade support in phosphor-bmc-code-mg= mt:

[CAUTION: This Email is from outside the Organiz= ation. Unless you trust the sender, Don=92t click links or open attachments= as it may be a Phishing email, which can steal your Information and compro= mise your Computer.]

On 2020-09-21 14:46, Patrick Williams wrote:
> On Mon, Sep 21, 2020 at 05:49:14PM +0000, P. Priyatharshan wrote:
>>
>> Hi ,
>>
>> Phosphor-software-manager currently supports bios upgrade for a si= ngle
>> host.I would like to propose a design to add multi host bios upgra= de
>> support in Phosphor-software-manager.
>>
>> Kindly review the below proposal and share your valuable comments.=
>>
>> Design:
>>
>> a) : Add Host Number
>>
>> 1) MANIFEST file change:
>>
>> Add host number in MANIFEST file, purpose field like below.<= br> >>
>> Ex:
>> For Host1,
>> purpose=3Dxyz.openbmc_project.Software.Version.VersionPurpose.Host= 1
>> For Host2,
>> purpose=3Dxyz.openbmc_project.Software.Version.VersionPurpose.Host= 2 and
>> So on.
>
> These 'purpose' values align with the Purpose field in Software.Versio= n
> (and the VersionPurpose enumeration). We really don't want to ad= d Host
> positions to this enumeration set.
>
> Why would a MANIFEST file have a different value for a different host<= br> > position anyhow? Isn't the appropriate firmware image for your h= ost
> 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 ha= ndled
> by ExtendedVersion.
>
> I can't imagine that a 16-blade BladeCenter would want to have 16
> different files for each slot in the BladeCenter. That doesn't s= ound
> like a great user experience.
>
>> 2) For bios upgrade, handle the same to incorporate the host numbe= r
>> and send host number to the systemd service
>> obmc-flash-host-bios@service like below.
>>
>>   if (host.empty())
>>     {
>>         auto biosServiceFi= le =3D "obmc-flash-host-bios@" + versionId +
>> ".service";
>>     }
>>     else
>>     {
>>         auto biosServiceFi= le =3D
>>           &= nbsp; "obmc-flash-host-bios@" + versionId + "_" + host = +
>> ".service";
>>     }
>
> It doesn't seem like systemd had a clear mechanism to create a
> 'multi-parameter template' which seems to be what you're asking for. > We
> should probably define a convention for openbmc. I'm somewhat > surprised
> that versionId is part of the template parameters to begin with.
>
> I think there is a question you've missed (assuming we're not using th= e
> purpose field to identify which host): How do we handle activation for=
> firmware images which can apply to multiple entities? Today, as = best I
> can tell, there is a 1:1 mapping between firmware images and inventory=
> items they apply on. At least, this is the case in
> phosphor-bmc-code-mgmt, which is where this code you linked to is.
>
> Reading the section "ItemUpdater" at [1], it seems that we c= an have
> multiple Activation interfaces for a single Software version and these=
> Activation interfaces are expected to be associated to the
> Inventory.Item they manage. This would mean that we should creat= e <N>
> activation objects, one for each host, and modifying
> `RequestedActivation` will activate only for that host.
>
> (Adriana can maybe weight in here?)

Agree with what Patrick has said.
One current limitation is the version id is generated from the firmware
version string, meaning that it can't be duplicate d-bus interfaces with the same version id.
One feature that I think will help with this multi-host scenario is that I'll be pushing up a change for review to generate the id based on
firmware version plus the device or volume where the firmware version
resides, thus allowing different multiple interfaces with the same
firmware version. The use-case is to allow BMCs that support two
firmware versions to have the same firmware on both sides.
This can then be used for multi-host by creating an Activation interface for each host even if the firmware image we want to install is the same
for multiple host targets, by using some unique identifier for each host instance to generate the id.

>
>>
>> b) : Implement a generic IPMI based multi-host bios upgrade.
>>
>> 1) This generic implementation expects a json config file with the=
>> details like IPMI net function , command id, and etc and process t= he
>> bios upgrade via ipmi commands.
>
> I'm not following how this is related unless this is the code inside > 'obmc-flash-host-bios@'? You're not expecting this IPMI function= to
> dynamically create your MANIFEST, are you? MANIFEST files need t= o be
> digitally signed when you're doing secure updates, so you cannot
> dynamically manipulate them.
>

The phosphor-bmc-code-mgmt repo manages out-of-band updates. Maybe the
IPMI flash repo[2] is relevant here? It has tools to do an inband update through IPMI to the bmc and host.

>
> 1.
> https://apc01.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fgithub.= com%2Fopenbmc%2Fphosphor-dbus-interfaces%2Ftree%2Fmaster%2Fxyz%2Fopenbmc_pr= oject%2FSoftware%23itemupdater&data=3D02%7C01%7CPriyatharshanP%40hc= l.com%7C230241680e504b3d447208d85e711c33%7C189de737c93a4f5a8b686f4ca9941912= %7C0%7C0%7C637363187181175557&sdata=3D4sGybP9lK0Xjuyds9rlyjuRtY8%2F= Y%2F6qMkDFP0hDhwaY%3D&reserved=3D0

2. https://apc01.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fgithub.= com%2Fopenbmc%2Fphosphor-ipmi-flash&data=3D02%7C01%7CPriyatharshanP= %40hcl.com%7C230241680e504b3d447208d85e711c33%7C189de737c93a4f5a8b686f4ca99= 41912%7C0%7C0%7C637363187181175557&sdata=3DyF2JTBCD6D2SAPcucHBQuiUn= SeOxnpI%2BOx37yjAJylU%3D&reserved=3D0

::DISCLAIMER::

The contents of this e-mail and any attachment(s) are confidential and inte= nded 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 con= tents (with or without referred errors) shall therefore not attach any liab= ility 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 messag= e without the prior written consent of authorized representative of HCL is strictly prohibited. If you have re= ceived this email in error please delete it and notify the sender immediate= ly. Before opening any email and/or attachments, please check them for viru= ses and other defects.

--_000_TY2PR04MB3311812DB85A11934F044FB4CA0C0TY2PR04MB3311apcp_--