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

[Patrick Williams]

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?)

> 
> 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.


1. https://github.com/openbmc/phosphor-dbus-interfaces/tree/master/xyz/openbmc_project/Software#itemupdater

-- 
Patrick Williams
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.ozlabs.org/pipermail/openbmc/attachments/20200921/d7767139/attachment.sig>