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

Tue Oct 20 04:08:13 AEDT 2020

[Vijay's Comment]
>Can we use extraversion field in manifest file to identify host id. In manifest file, if purpose is >host then we can check extra version and >find out which host it is applicable for.

 [Priyatharshan Response]
We have already brought up the point of using manifest file. As a response, Patrick mentioned as
"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".

[Vijay's Comment]
>Or lese we can add another property in /xyz/openbmc_project/software,
>name as host id and user can set this property after uploading image.
>I don’t agree with creating multiple interfaces for single image
>upgrade. Because image will be deleted after successful activation.

 [Priyatharshan Response]
Your suggestion of adding "host id" property is a good idea, but has few caveates
*. If the image is deleted after programming each host, this brings a sequential nature where bios upgrade time prolongs as many times in multi-host environment (for ex 16-BladeCenter)
*. the image needs to be copied into the target every time and the upgrades needs to be started. The bios.bin file copy causes additional delay in the upgradation
Based on the approach which we porposed,
*. with the single bios image, multiple host can be upgraded using "RequestActivation" in each interface without deleting the bios image
*. as it is multi object approach (one for each host), multiple host could be programmed concurrently
This would save bios upgrade time.

@Vijay Khemka @patrick at stwcx.xyz @Adriana Kobylak: Kindly share your thoughts on this.

Thanks,
Priyatharshan P
________________________________
From: Vijay Khemka <vijaykhemka at fb.com>
Sent: 16 October 2020 00:58
To: P. Priyatharshan <PriyatharshanP at hcl.com>; Adriana Kobylak <anoo at linux.ibm.com>
Cc: 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>; Velumani T-ERS,HCLTech <velumanit at hcl.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.]

Can we use extraversion field in manifest file to identify host id.

In manifest file, if purpose is host then we can check extra version

and find out which host it is applicable for.

Or lese we can add another property in /xyz/openbmc_project/software,

name as host id and user can set this property after uploading image.

I don’t agree with creating multiple interfaces for single image

upgrade.  Because image will be deleted after successful activation.

From: openbmc <openbmc-bounces+vijaykhemka=fb.com at lists.ozlabs.org> on behalf of "P. Priyatharshan" <PriyatharshanP at hcl.com>
Date: Thursday, October 15, 2020 at 10:18 AM
To: Adriana Kobylak <anoo at linux.ibm.com>
Cc: "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>, "Velumani T-ERS, HCLTech" <velumanit at hcl.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:

Thanks Adriana for the clarification.

For host bios update, the images will be copied to BMC(/tmp/images) and will start flashing by making RequestedActivation field "xyz.openbmc_project.Software.Activation.RequestedActivations.Active". In our case, the device location will be same for all the bios images (BMC /tmp/images).So I think the above design you proposed[id = version+volume ID]  may not work effectively for multi host as the id is still going to be same for all the hosts.

We would like to propose the following approach for your review.Kindly go through the below steps and share your valuable suggestions.

1.Number of host will be identified from machine layer [OBMC_HOST_INSTANCES]

2.Code will be modified to create n number of objects based on number of hosts

  Ex: Log taken in YosemiteV2 [4 host]

root at yosemitev2:~# busctl tree xyz.openbmc_project.Software.BMC.Updater

`-/xyz

  `-/xyz/openbmc_project

    `-/xyz/openbmc_project/software

      |-/xyz/openbmc_project/software/1929c585

      |-/xyz/openbmc_project/software/host1

      | `-/xyz/openbmc_project/software/host1/28bd62d9

      |-/xyz/openbmc_project/software/host2

      | `-/xyz/openbmc_project/software/host2/28bd62d9

      |-/xyz/openbmc_project/software/host3

      | `-/xyz/openbmc_project/software/host3/28bd62d9

      `-/xyz/openbmc_project/software/host4

        `-/xyz/openbmc_project/software/host4/28bd62d9

root at yosemitev2:~# busctl tree xyz.openbmc_project.Software.Version

`-/xyz

  `-/xyz/openbmc_project

    `-/xyz/openbmc_project/software

      |-/xyz/openbmc_project/software/host1

      | `-/xyz/openbmc_project/software/host1/28bd62d9

      |-/xyz/openbmc_project/software/host2

      | `-/xyz/openbmc_project/software/host2/28bd62d9

      |-/xyz/openbmc_project/software/host3

      | `-/xyz/openbmc_project/software/host3/28bd62d9

      `-/xyz/openbmc_project/software/host4

        `-/xyz/openbmc_project/software/host4/28bd62d9

3.This will create activation interface for each host. For a multi-host system if the  RequestedActivation is set to "xyz.openbmc_project.Software.Activation.RequestedActivations.Active", then different bios service file will be called based the host.

For single host : biosServiceFile = "obmc-flash-host-bios@" + versionId + ".service";

For multi host  : biosServiceFile =  "obmc-flash-host" + host + "-bios@" + versionId + ".service";

Then it can be used for multi host even if the firmware image we want to install is the same for multiple host targets.

I have created a WIP patch for the design proposed above.Kindly have a glance and share your comments.

https://gerrit.openbmc-project.xyz/c/openbmc/phosphor-bmc-code-mgmt/+/37448<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%7C360bd4e12c3f4766c18708d87140813c%7C189de737c93a4f5a8b686f4ca9941912%7C0%7C0%7C637383869156208822%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=mCKg9YzRECFzIbB0Mp78FH6r5SbSXzWs2HZG4RSHo%2Bs%3D&reserved=0>

Thanks,

Priyatharshan P

________________________________

From: Adriana Kobylak <anoo at linux.ibm.com>
Sent: 06 October 2020 03:11
To: P. Priyatharshan <PriyatharshanP at hcl.com>
Cc: Patrick Williams <patrick at stwcx.xyz>; 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.]

Hi Priyatharshan,

>  Object : /xyz/openbmc_project/software/[FIRMWARE_VERSION]_[DEVICE]
> where device could be host1, 2, ...,N
>  Interface : xyz.openbmc_project.Software.Activation
>
>  Please confirm if our understanding is correct.

I meant that to generate the id, which currently uses the version
string, would instead use the version string plus the string for the
name of the device where it's stored in order to generate the hash. For
example, today the code calls "SHA512_Update("version")", where
"version" is for example "2.9.0-dev-663-g2e34bb673". Instead the code
would detect this version is stored let's say in device "mtd1" or
"mmcblk0p1", it'd then append that device string to version, ex:
"2.9.0-dev-663-g2e34bb673-mmcblk0p1" and pass that string to
SHA512_Update(), therefore creating a different hash depending where
that version of bmc code is stored.

Note that this is for BMC versions only. We discussed that for host
versions, we'd need to modify the code to add a "os-release" file under
/media/ that contained the host version information similar to the BMC's
os-release file. In addition, we'd need to somehow determine that those
files were for host (Bios) versions instead of BMC ones. Perhaps
os-release could have an additional field added to specify the purpose.

> Adriana, Any tentative timeline on your commits availability [generate
> the id based on firmware version plus the device or volume ]

I'd say by early next year at the latest.

::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/20201019/bd16ae25/attachment-0001.htm>