Multi host bios upgrade support in phosphor-bmc-code-mgmt:

[Adriana Kobylak]

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://github.com/openbmc/phosphor-dbus-interfaces/tree/master/xyz/openbmc_project/Software#itemupdater

2. https://github.com/openbmc/phosphor-ipmi-flash