Multi host bios upgrade support in phosphor-bmc-code-mgmt:
P. Priyatharshan
PriyatharshanP at hcl.com
Tue Oct 6 04:29:25 AEDT 2020
Adriana : 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.
Priyatharshan : Thanks for the info.. It seems IPMI-flash repo does not suit our requirements as it provides support only for IPMI not for IPMB.
Adriana, Any tentative timeline on your commits availability [generate the id based on firmware version plus the device or volume ]
Thanks,
Priyatharshan P
________________________________
From: P. Priyatharshan <PriyatharshanP at hcl.com>
Sent: 01 October 2020 21:22
To: Adriana Kobylak <anoo at linux.ibm.com>; Patrick Williams <patrick at stwcx.xyz>
Cc: Velumani T-ERS,HCLTech <velumanit at hcl.com>; openbmc at lists.ozlabs.org <openbmc at lists.ozlabs.org>; anoo at us.ibm.com <anoo at us.ibm.com>; ojayanth at in.ibm.com <ojayanth at in.ibm.com>; gmills at linux.vnet.ibm.com <gmills at linux.vnet.ibm.com>; ratagupt at linux.vnet.ibm.com <ratagupt at linux.vnet.ibm.com>
Subject: Re: Multi host bios upgrade support in phosphor-bmc-code-mgmt:
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 mentioned below,
Dbus : xyz.openbmc_project.Software.BMC.Updater
Object : /xyz/openbmc_project/software/[firmware_version]
Interface : xyz.openbmc_project.Software.Activation
For multi host with same firmware version id generation changes,
Dbus : xyz.openbmc_project.Software.BMC.Updater
Object : /xyz/openbmc_project/software/[firmware_version]_[device] where device could be host1, 2, ...,N
Interface : xyz.openbmc_project.Software.Activation
We also expect that the interface (xyz.openbmc_project.Software.Activation) will be created for each object (/xyz/openbmc_project/software/[firmware_version]_[device])
Please confirm if our understanding is correct.
Thanks,
Priyatharshan P
________________________________
From: Adriana Kobylak <anoo at linux.ibm.com>
Sent: 22 September 2020 02:28
To: Patrick Williams <patrick at stwcx.xyz>
Cc: P. Priyatharshan <PriyatharshanP at hcl.com>; Sundaramoorthy Thiyagarajan <sundaramoorthyt at hcl.com>; Velumani T-ERS,HCLTech <velumanit at hcl.com>; openbmc at lists.ozlabs.org <openbmc at lists.ozlabs.org>; anoo at us.ibm.com <anoo at us.ibm.com>; ojayanth at in.ibm.com <ojayanth at in.ibm.com>; gmills at linux.vnet.ibm.com <gmills at linux.vnet.ibm.com>; ratagupt at linux.vnet.ibm.com <ratagupt at linux.vnet.ibm.com>
Subject: Re: Multi host bios upgrade support in phosphor-bmc-code-mgmt:
[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.]
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 single
>> host.I would like to propose a design to add multi host bios upgrade
>> 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.
>>
>> Ex:
>> For Host1,
>> purpose=xyz.openbmc_project.Software.Version.VersionPurpose.Host1
>> For Host2,
>> purpose=xyz.openbmc_project.Software.Version.VersionPurpose.Host2 and
>> So on.
>
> These 'purpose' values align with the Purpose field in Software.Version
> (and the VersionPurpose enumeration). We really don't want to add Host
> positions to this enumeration set.
>
> Why would a MANIFEST file have a different value for a different host
> position anyhow? Isn't the appropriate firmware image for your host
> card dependent on which host-card-hardware you have installed and not
> which position the card is in? The type of hardware should be handled
> 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 sound
> like a great user experience.
>
>> 2) For bios upgrade, handle the same to incorporate the host number
>> and send host number to the systemd service
>> obmc-flash-host-bios at service like below.
>>
>> if (host.empty())
>> {
>> auto biosServiceFile = "obmc-flash-host-bios@" + versionId +
>> ".service";
>> }
>> else
>> {
>> auto biosServiceFile =
>> "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 the
> 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 can 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 create <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 the
>> 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 to 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=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
2. 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
::DISCLAIMER::
________________________________
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.
________________________________
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ozlabs.org/pipermail/openbmc/attachments/20201005/bcccffa6/attachment-0001.htm>
More information about the openbmc
mailing list