Multi host bios upgrade support in phosphor-bmc-code-mgmt:
Adriana Kobylak
anoo at linux.ibm.com
Sat Oct 31 05:52:32 AEDT 2020
On 2020-10-28 10:20, P. Priyatharshan wrote:
> A Gentle Reminder.. Partrick/Adriyana/Vijay, Kindly share your
> thoughts...
>
> This Message Is From an External Sender
>
> This message came from outside your organization.
>
> A Gentle Reminder..
>
> Partrick/Adriyana/Vijay,
>
> Kindly share your thoughts whether the below approach can be
> implemented.
I don't have additional comments, just questions about what are the
details of the implementation. I'd suggest filling up a design document
template[1]. Then we can review what's being proposed, and what are
alternatives that were considered. Also it should include how the
Redfish interfaces will look like, and how the user will interact with
them, for example would a user know which host corresponds to interface
'host0' (or whatever the name is in the Redfish interface), how the user
would specify which instances to update, etc.
Besides those details, the the proposal should be compatible with the
existing implementation of the software interfaces and version id.
1:
https://github.com/openbmc/docs/blob/master/designs/design-template.md
>
>> Adriana's below approach could also be considered for implementation.
> Please suggest.
>
>>> One thought is to create a property that the user specifies for
> which
>>> Host they want to update. This would require creating the
>>> /xyz/openbmc_project/software/hostX interfaces and the new property
> when
>>> the BMC starts up. Then for example:
>>> - User sets the new "this should be updated" property for host1 and
>
>>> host3.
>>> - User calls the Redfish API and select the bios image to upload.
>>> - The BMC updater sees it's a host bios image and creates
>>> hostX/<versionid> interfaces
>>> - THe BMC updater calls the bios_X updater script for only the host
>
>>> instances that have the "this should be updated" property set.
>
>> The image can be deleted after successfully updating all the hosts
> having "this should be updated" property set.
>
> Thanks,
> Priyatharshan P
>
> -------------------------
>
> FROM: P. Priyatharshan <PriyatharshanP at hcl.com>
> SENT: 23 October 2020 19:04
> TO: Vijay Khemka <vijaykhemka at fb.com>; Adriana Kobylak
> <anoo at linux.ibm.com>
> CC: patrick at stwcx.xyz <patrick at stwcx.xyz>; 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:
>
> Partrick/Adriyana/Vijay, Can you please help finalyzing the approach?
> Based on that we will start the implementation.
>
> Thanks,
> Priyatharshan P
>
> -------------------------
>
> FROM: P. Priyatharshan <PriyatharshanP at hcl.com>
> SENT: 21 October 2020 10:57
> TO: Vijay Khemka <vijaykhemka at fb.com>; Adriana Kobylak
> <anoo at linux.ibm.com>
> CC: patrick at stwcx.xyz <patrick at stwcx.xyz>; 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:
>
> Hi Vijay,
>
> As mentioned, the MANIFEST file approach was discussed already. As it
> is a factory ship-out, it may not be appropriate to add the host IDs
> into it.
>
> Partrik was also not inclined towards adding host id into MANIFEST
> file. Provided below Ptricks response for reference.
>
>> 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
>
> @Patrick, @Adriana Your comments/suggestion helps.
>
> Adriana's below approach could also be considered for implementation.
> Please suggest.
>
>> One thought is to create a property that the user specifies for
> which
>> Host they want to update. This would require creating the
>> /xyz/openbmc_project/software/hostX interfaces and the new property
> when
>> the BMC starts up. Then for example:
>> - User sets the new "this should be updated" property for host1 and
>> host3.
>> - User calls the Redfish API and select the bios image to upload.
>> - The BMC updater sees it's a host bios image and creates
>> hostX/<versionid> interfaces
>> - THe BMC updater calls the bios_X updater script for only the host
>> instances that have the "this should be updated" property set.
>
> The image can be deleted after successfully updating all the hosts
> having "this should be updated" property set.
>
> Thanks, Priyatharshan P
>
> -------------------------
>
> FROM: Vijay Khemka <vijaykhemka at fb.com>
> SENT: 21 October 2020 05:40
> TO: Adriana Kobylak <anoo at linux.ibm.com>; P. Priyatharshan
> <PriyatharshanP at hcl.com>
> CC: patrick at stwcx.xyz <patrick at stwcx.xyz>; 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.]
>
> I have another idea of mentioning host details in manifest file to
> have single
> upload only. You can put a single host id or an array of host id in
> extra version.
> Format can be defined, this way as soon as we see bios image uploaded
> and
> based on extra version, it will create as many version interface and
> allow to
> activate them. Once we call all the bios upgrade script, we should
> delete
> image.
>
> On 10/19/20, 12:26 PM, "Adriana Kobylak" <anoo at linux.ibm.com>
> wrote:
>
> Vijay is correct in that today the image file is deleted after a
> successful activation. Therefore today's logic will for example
> delete
> the file from /tmp/images/ after Host1 was updated, and a subsequent
> request to update Host2 would fail because the image file would not
> exist anymore. The reason for deleting the file is to preserve space
> since the file is assumed that it's not needed anymore after it was
> used
> for activation. Otherwise we can potentially fill up the /tmp space.
>
> Let's say we keep the image files around forever in /tmp/images/,
> next
> I'm thinking about the Redfish API where the upload and activation is
> a
> single step, we'd need to figure out how to specify which Host
> instances
> should be updated.
>
> One thought is to create a property that the user specifies for which
> Host they want to update. This would require creating the
> /xyz/openbmc_project/software/hostX interfaces and the new property
> when
> the BMC starts up. Then for example:
> - User sets the new "this should be updated" property for host1 and
> host3.
> - User calls the Redfish API and select the bios image to upload.
> - The BMC updater sees it's a host bios image and creates
> hostX/<versionid> interfaces
> - THe BMC updater calls the bios_X updater script for only the host
> instances that have the "this should be updated" property set.
>
> It'd also be good if you could check if Redfish has an ability to
> somehow specify the target that needs to be updated, or if others
> have
> implemented this ability in some other way.
>
> On 2020-10-19 12:08, P. Priyatharshan wrote:
> > [Vijay's Comment] >Can we use extraversion field in manifest file
> to
> > identify host...
> >
> > This Message Is From an External Sender
> >
> > This message came from outside your organization.
> >
> > [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://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%7Cef0c97b4694f44db53a508d87555c902%7C189de737c93a4f5a8b686f4ca9941912%7C0%7C0%7C637388358605381286%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=SWOdfla2MDRK4ostBDNzozQBpoyNdyvDNXPMpQo05Tk%3D&reserved=0
> [1]
> > [1]
> >
> > 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.
> >
> > -------------------------
> >
> >
> > Links:
> > ------
> > [1]
> >
> 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%7Cef0c97b4694f44db53a508d87555c902%7C189de737c93a4f5a8b686f4ca9941912%7C0%7C0%7C637388358605381286%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=SWOdfla2MDRK4ostBDNzozQBpoyNdyvDNXPMpQo05Tk%3D&reserved=0
> [1]
>
>
>
> Links:
> ------
> [1]
> 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%7Cef0c97b4694f44db53a508d87555c902%7C189de737c93a4f5a8b686f4ca9941912%7C0%7C0%7C637388358605381286%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=SWOdfla2MDRK4ostBDNzozQBpoyNdyvDNXPMpQo05Tk%3D&reserved=0
More information about the openbmc
mailing list