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

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

[P. Priyatharshan]

[-- Attachment #1: Type: text/plain, Size: 2345 bytes --]


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.

2) For bios upgrade, handle the same to incorporate the host number and send host number to the systemd service obmc-flash-host-bios@service like below.

  if (host.empty())
    {
        auto biosServiceFile = "obmc-flash-host-bios@" + versionId + ".service";
    }
    else
    {
        auto biosServiceFile =
            "obmc-flash-host-bios@" + versionId + "_" + host + ".service";
    }

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.


Thanks,
Priyatharshan P
::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.
________________________________

[-- Attachment #2: Type: text/html, Size: 3818 bytes --]

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

[P. Priyatharshan]

[-- Attachment #1: Type: text/plain, Size: 2345 bytes --]


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.

2) For bios upgrade, handle the same to incorporate the host number and send host number to the systemd service obmc-flash-host-bios@service like below.

  if (host.empty())
    {
        auto biosServiceFile = "obmc-flash-host-bios@" + versionId + ".service";
    }
    else
    {
        auto biosServiceFile =
            "obmc-flash-host-bios@" + versionId + "_" + host + ".service";
    }

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.


Thanks,
Priyatharshan P
::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.
________________________________

[-- Attachment #2: Type: text/html, Size: 3818 bytes --]

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

[Patrick Williams]

[-- Attachment #1: Type: text/plain, Size: 3566 bytes --]

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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

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

[Patrick Williams]

[-- Attachment #1: Type: text/plain, Size: 3566 bytes --]

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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: 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@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

Re: 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@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

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

[P. Priyatharshan]

[-- Attachment #1: Type: text/plain, Size: 8460 bytes --]

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@linux.ibm.com>
Sent: 22 September 2020 02:28
To: Patrick Williams <patrick@stwcx.xyz>
Cc: P. Priyatharshan <PriyatharshanP@hcl.com>; Sundaramoorthy Thiyagarajan <sundaramoorthyt@hcl.com>; Velumani T-ERS,HCLTech <velumanit@hcl.com>; openbmc@lists.ozlabs.org <openbmc@lists.ozlabs.org>; anoo@us.ibm.com <anoo@us.ibm.com>; ojayanth@in.ibm.com <ojayanth@in.ibm.com>; gmills@linux.vnet.ibm.com <gmills@linux.vnet.ibm.com>; ratagupt@linux.vnet.ibm.com <ratagupt@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@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&amp;data=02%7C01%7CPriyatharshanP%40hcl.com%7C230241680e504b3d447208d85e711c33%7C189de737c93a4f5a8b686f4ca9941912%7C0%7C0%7C637363187181175557&amp;sdata=4sGybP9lK0Xjuyds9rlyjuRtY8%2FY%2F6qMkDFP0hDhwaY%3D&amp;reserved=0

2. https://apc01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fopenbmc%2Fphosphor-ipmi-flash&amp;data=02%7C01%7CPriyatharshanP%40hcl.com%7C230241680e504b3d447208d85e711c33%7C189de737c93a4f5a8b686f4ca9941912%7C0%7C0%7C637363187181175557&amp;sdata=yF2JTBCD6D2SAPcucHBQuiUnSeOxnpI%2BOx37yjAJylU%3D&amp;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.
________________________________

[-- Attachment #2: Type: text/html, Size: 12711 bytes --]

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

[P. Priyatharshan]

[-- Attachment #1: Type: text/plain, Size: 9528 bytes --]


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@hcl.com>
Sent: 01 October 2020 21:22
To: Adriana Kobylak <anoo@linux.ibm.com>; Patrick Williams <patrick@stwcx.xyz>
Cc: Velumani T-ERS,HCLTech <velumanit@hcl.com>; openbmc@lists.ozlabs.org <openbmc@lists.ozlabs.org>; anoo@us.ibm.com <anoo@us.ibm.com>; ojayanth@in.ibm.com <ojayanth@in.ibm.com>; gmills@linux.vnet.ibm.com <gmills@linux.vnet.ibm.com>; ratagupt@linux.vnet.ibm.com <ratagupt@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@linux.ibm.com>
Sent: 22 September 2020 02:28
To: Patrick Williams <patrick@stwcx.xyz>
Cc: P. Priyatharshan <PriyatharshanP@hcl.com>; Sundaramoorthy Thiyagarajan <sundaramoorthyt@hcl.com>; Velumani T-ERS,HCLTech <velumanit@hcl.com>; openbmc@lists.ozlabs.org <openbmc@lists.ozlabs.org>; anoo@us.ibm.com <anoo@us.ibm.com>; ojayanth@in.ibm.com <ojayanth@in.ibm.com>; gmills@linux.vnet.ibm.com <gmills@linux.vnet.ibm.com>; ratagupt@linux.vnet.ibm.com <ratagupt@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@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&amp;data=02%7C01%7CPriyatharshanP%40hcl.com%7C230241680e504b3d447208d85e711c33%7C189de737c93a4f5a8b686f4ca9941912%7C0%7C0%7C637363187181175557&amp;sdata=4sGybP9lK0Xjuyds9rlyjuRtY8%2FY%2F6qMkDFP0hDhwaY%3D&amp;reserved=0

2. https://apc01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fopenbmc%2Fphosphor-ipmi-flash&amp;data=02%7C01%7CPriyatharshanP%40hcl.com%7C230241680e504b3d447208d85e711c33%7C189de737c93a4f5a8b686f4ca9941912%7C0%7C0%7C637363187181175557&amp;sdata=yF2JTBCD6D2SAPcucHBQuiUnSeOxnpI%2BOx37yjAJylU%3D&amp;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.
________________________________

[-- Attachment #2: Type: text/html, Size: 15141 bytes --]

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

[Adriana Kobylak]

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.

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

[P. Priyatharshan]

[-- Attachment #1: Type: text/plain, Size: 6162 bytes --]

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

Thanks,
Priyatharshan P

________________________________
From: Adriana Kobylak <anoo@linux.ibm.com>
Sent: 06 October 2020 03:11
To: P. Priyatharshan <PriyatharshanP@hcl.com>
Cc: Patrick Williams <patrick@stwcx.xyz>; Velumani T-ERS,HCLTech <velumanit@hcl.com>; openbmc@lists.ozlabs.org <openbmc@lists.ozlabs.org>; anoo@us.ibm.com <anoo@us.ibm.com>; ojayanth@in.ibm.com <ojayanth@in.ibm.com>; gmills@linux.vnet.ibm.com <gmills@linux.vnet.ibm.com>; ratagupt@linux.vnet.ibm.com <ratagupt@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.
________________________________

[-- Attachment #2: Type: text/html, Size: 8655 bytes --]

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

[Vijay Khemka]

[-- Attachment #1: Type: text/plain, Size: 7306 bytes --]

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@lists.ozlabs.org> on behalf of "P. Priyatharshan" <PriyatharshanP@hcl.com>
Date: Thursday, October 15, 2020 at 10:18 AM
To: Adriana Kobylak <anoo@linux.ibm.com>
Cc: "openbmc@lists.ozlabs.org" <openbmc@lists.ozlabs.org>, "anoo@us.ibm.com" <anoo@us.ibm.com>, "ojayanth@in.ibm.com" <ojayanth@in.ibm.com>, "gmills@linux.vnet.ibm.com" <gmills@linux.vnet.ibm.com>, "Velumani T-ERS, HCLTech" <velumanit@hcl.com>, "ratagupt@linux.vnet.ibm.com" <ratagupt@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@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@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://gerrit.openbmc-project.xyz/c/openbmc/phosphor-bmc-code-mgmt/+/37448>

Thanks,
Priyatharshan P

________________________________
From: Adriana Kobylak <anoo@linux.ibm.com>
Sent: 06 October 2020 03:11
To: P. Priyatharshan <PriyatharshanP@hcl.com>
Cc: Patrick Williams <patrick@stwcx.xyz>; Velumani T-ERS,HCLTech <velumanit@hcl.com>; openbmc@lists.ozlabs.org <openbmc@lists.ozlabs.org>; anoo@us.ibm.com <anoo@us.ibm.com>; ojayanth@in.ibm.com <ojayanth@in.ibm.com>; gmills@linux.vnet.ibm.com <gmills@linux.vnet.ibm.com>; ratagupt@linux.vnet.ibm.com <ratagupt@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.
________________________________

[-- Attachment #2: Type: text/html, Size: 17205 bytes --]

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

[P. Priyatharshan]

[-- Attachment #1: Type: text/plain, Size: 10300 bytes --]

[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@stwcx.xyz @Adriana Kobylak: Kindly share your thoughts on this.

Thanks,
Priyatharshan P
________________________________
From: Vijay Khemka <vijaykhemka@fb.com>
Sent: 16 October 2020 00:58
To: P. Priyatharshan <PriyatharshanP@hcl.com>; Adriana Kobylak <anoo@linux.ibm.com>
Cc: openbmc@lists.ozlabs.org <openbmc@lists.ozlabs.org>; anoo@us.ibm.com <anoo@us.ibm.com>; ojayanth@in.ibm.com <ojayanth@in.ibm.com>; gmills@linux.vnet.ibm.com <gmills@linux.vnet.ibm.com>; Velumani T-ERS,HCLTech <velumanit@hcl.com>; ratagupt@linux.vnet.ibm.com <ratagupt@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@lists.ozlabs.org> on behalf of "P. Priyatharshan" <PriyatharshanP@hcl.com>
Date: Thursday, October 15, 2020 at 10:18 AM
To: Adriana Kobylak <anoo@linux.ibm.com>
Cc: "openbmc@lists.ozlabs.org" <openbmc@lists.ozlabs.org>, "anoo@us.ibm.com" <anoo@us.ibm.com>, "ojayanth@in.ibm.com" <ojayanth@in.ibm.com>, "gmills@linux.vnet.ibm.com" <gmills@linux.vnet.ibm.com>, "Velumani T-ERS, HCLTech" <velumanit@hcl.com>, "ratagupt@linux.vnet.ibm.com" <ratagupt@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@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@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@linux.ibm.com>
Sent: 06 October 2020 03:11
To: P. Priyatharshan <PriyatharshanP@hcl.com>
Cc: Patrick Williams <patrick@stwcx.xyz>; Velumani T-ERS,HCLTech <velumanit@hcl.com>; openbmc@lists.ozlabs.org <openbmc@lists.ozlabs.org>; anoo@us.ibm.com <anoo@us.ibm.com>; ojayanth@in.ibm.com <ojayanth@in.ibm.com>; gmills@linux.vnet.ibm.com <gmills@linux.vnet.ibm.com>; ratagupt@linux.vnet.ibm.com <ratagupt@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.

________________________________

[-- Attachment #2: Type: text/html, Size: 20287 bytes --]

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

[Adriana Kobylak]

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@stwcx.xyz @Adriana Kobylak: Kindly share your
> thoughts on this.
> 
>  Thanks,
>  Priyatharshan P
> 
> -------------------------
> 
> FROM: Vijay Khemka <vijaykhemka@fb.com>
>  SENT: 16 October 2020 00:58
>  TO: P. Priyatharshan <PriyatharshanP@hcl.com>; Adriana Kobylak
> <anoo@linux.ibm.com>
>  CC: openbmc@lists.ozlabs.org <openbmc@lists.ozlabs.org>;
> anoo@us.ibm.com <anoo@us.ibm.com>; ojayanth@in.ibm.com
> <ojayanth@in.ibm.com>; gmills@linux.vnet.ibm.com
> <gmills@linux.vnet.ibm.com>; Velumani T-ERS,HCLTech
> <velumanit@hcl.com>; ratagupt@linux.vnet.ibm.com
> <ratagupt@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@lists.ozlabs.org> on
> behalf of "P. Priyatharshan" <PriyatharshanP@hcl.com>
>  DATE: Thursday, October 15, 2020 at 10:18 AM
>  TO: Adriana Kobylak <anoo@linux.ibm.com>
>  CC: "openbmc@lists.ozlabs.org" <openbmc@lists.ozlabs.org>,
> "anoo@us.ibm.com" <anoo@us.ibm.com>, "ojayanth@in.ibm.com"
> <ojayanth@in.ibm.com>, "gmills@linux.vnet.ibm.com"
> <gmills@linux.vnet.ibm.com>, "Velumani T-ERS, HCLTech"
> <velumanit@hcl.com>, "ratagupt@linux.vnet.ibm.com"
> <ratagupt@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@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@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
> [1]
> 
> Thanks,
> 
> Priyatharshan P
> 
> -------------------------
> 
> FROM: Adriana Kobylak <anoo@linux.ibm.com>
>  SENT: 06 October 2020 03:11
>  TO: P. Priyatharshan <PriyatharshanP@hcl.com>
>  CC: Patrick Williams <patrick@stwcx.xyz>; Velumani T-ERS,HCLTech
> <velumanit@hcl.com>; openbmc@lists.ozlabs.org
> <openbmc@lists.ozlabs.org>; anoo@us.ibm.com <anoo@us.ibm.com>;
> ojayanth@in.ibm.com <ojayanth@in.ibm.com>; gmills@linux.vnet.ibm.com
> <gmills@linux.vnet.ibm.com>; ratagupt@linux.vnet.ibm.com
> <ratagupt@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&amp;data=04%7C01%7CPriyatharshanP%40hcl.com%7C360bd4e12c3f4766c18708d87140813c%7C189de737c93a4f5a8b686f4ca9941912%7C0%7C0%7C637383869156208822%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=mCKg9YzRECFzIbB0Mp78FH6r5SbSXzWs2HZG4RSHo%2Bs%3D&amp;reserved=0

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

[Vijay Khemka]

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@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@stwcx.xyz @Adriana Kobylak: Kindly share your
    > thoughts on this.
    > 
    >  Thanks,
    >  Priyatharshan P
    > 
    > -------------------------
    > 
    > FROM: Vijay Khemka <vijaykhemka@fb.com>
    >  SENT: 16 October 2020 00:58
    >  TO: P. Priyatharshan <PriyatharshanP@hcl.com>; Adriana Kobylak
    > <anoo@linux.ibm.com>
    >  CC: openbmc@lists.ozlabs.org <openbmc@lists.ozlabs.org>;
    > anoo@us.ibm.com <anoo@us.ibm.com>; ojayanth@in.ibm.com
    > <ojayanth@in.ibm.com>; gmills@linux.vnet.ibm.com
    > <gmills@linux.vnet.ibm.com>; Velumani T-ERS,HCLTech
    > <velumanit@hcl.com>; ratagupt@linux.vnet.ibm.com
    > <ratagupt@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@lists.ozlabs.org> on
    > behalf of "P. Priyatharshan" <PriyatharshanP@hcl.com>
    >  DATE: Thursday, October 15, 2020 at 10:18 AM
    >  TO: Adriana Kobylak <anoo@linux.ibm.com>
    >  CC: "openbmc@lists.ozlabs.org" <openbmc@lists.ozlabs.org>,
    > "anoo@us.ibm.com" <anoo@us.ibm.com>, "ojayanth@in.ibm.com"
    > <ojayanth@in.ibm.com>, "gmills@linux.vnet.ibm.com"
    > <gmills@linux.vnet.ibm.com>, "Velumani T-ERS, HCLTech"
    > <velumanit@hcl.com>, "ratagupt@linux.vnet.ibm.com"
    > <ratagupt@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@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@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 
    > [1]
    > 
    > Thanks,
    > 
    > Priyatharshan P
    > 
    > -------------------------
    > 
    > FROM: Adriana Kobylak <anoo@linux.ibm.com>
    >  SENT: 06 October 2020 03:11
    >  TO: P. Priyatharshan <PriyatharshanP@hcl.com>
    >  CC: Patrick Williams <patrick@stwcx.xyz>; Velumani T-ERS,HCLTech
    > <velumanit@hcl.com>; openbmc@lists.ozlabs.org
    > <openbmc@lists.ozlabs.org>; anoo@us.ibm.com <anoo@us.ibm.com>;
    > ojayanth@in.ibm.com <ojayanth@in.ibm.com>; gmills@linux.vnet.ibm.com
    > <gmills@linux.vnet.ibm.com>; ratagupt@linux.vnet.ibm.com
    > <ratagupt@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&amp;data=04%7C01%7CPriyatharshanP%40hcl.com%7C360bd4e12c3f4766c18708d87140813c%7C189de737c93a4f5a8b686f4ca9941912%7C0%7C0%7C637383869156208822%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=mCKg9YzRECFzIbB0Mp78FH6r5SbSXzWs2HZG4RSHo%2Bs%3D&amp;reserved=0 

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

[P. Priyatharshan]

[-- Attachment #1: Type: text/plain, Size: 16940 bytes --]

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@fb.com>
Sent: 21 October 2020 05:40
To: Adriana Kobylak <anoo@linux.ibm.com>; P. Priyatharshan <PriyatharshanP@hcl.com>
Cc: patrick@stwcx.xyz <patrick@stwcx.xyz>; openbmc@lists.ozlabs.org <openbmc@lists.ozlabs.org>; anoo@us.ibm.com <anoo@us.ibm.com>; ojayanth@in.ibm.com <ojayanth@in.ibm.com>; gmills@linux.vnet.ibm.com <gmills@linux.vnet.ibm.com>; Velumani T-ERS,HCLTech <velumanit@hcl.com>; ratagupt@linux.vnet.ibm.com <ratagupt@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@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@stwcx.xyz @Adriana Kobylak: Kindly share your
    > thoughts on this.
    >
    >  Thanks,
    >  Priyatharshan P
    >
    > -------------------------
    >
    > FROM: Vijay Khemka <vijaykhemka@fb.com>
    >  SENT: 16 October 2020 00:58
    >  TO: P. Priyatharshan <PriyatharshanP@hcl.com>; Adriana Kobylak
    > <anoo@linux.ibm.com>
    >  CC: openbmc@lists.ozlabs.org <openbmc@lists.ozlabs.org>;
    > anoo@us.ibm.com <anoo@us.ibm.com>; ojayanth@in.ibm.com
    > <ojayanth@in.ibm.com>; gmills@linux.vnet.ibm.com
    > <gmills@linux.vnet.ibm.com>; Velumani T-ERS,HCLTech
    > <velumanit@hcl.com>; ratagupt@linux.vnet.ibm.com
    > <ratagupt@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@lists.ozlabs.org> on
    > behalf of "P. Priyatharshan" <PriyatharshanP@hcl.com>
    >  DATE: Thursday, October 15, 2020 at 10:18 AM
    >  TO: Adriana Kobylak <anoo@linux.ibm.com>
    >  CC: "openbmc@lists.ozlabs.org" <openbmc@lists.ozlabs.org>,
    > "anoo@us.ibm.com" <anoo@us.ibm.com>, "ojayanth@in.ibm.com"
    > <ojayanth@in.ibm.com>, "gmills@linux.vnet.ibm.com"
    > <gmills@linux.vnet.ibm.com>, "Velumani T-ERS, HCLTech"
    > <velumanit@hcl.com>, "ratagupt@linux.vnet.ibm.com"
    > <ratagupt@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@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@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&amp;data=04%7C01%7CPriyatharshanP%40hcl.com%7Cef0c97b4694f44db53a508d87555c902%7C189de737c93a4f5a8b686f4ca9941912%7C0%7C0%7C637388358605381286%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=SWOdfla2MDRK4ostBDNzozQBpoyNdyvDNXPMpQo05Tk%3D&amp;reserved=0
    > [1]
    >
    > Thanks,
    >
    > Priyatharshan P
    >
    > -------------------------
    >
    > FROM: Adriana Kobylak <anoo@linux.ibm.com>
    >  SENT: 06 October 2020 03:11
    >  TO: P. Priyatharshan <PriyatharshanP@hcl.com>
    >  CC: Patrick Williams <patrick@stwcx.xyz>; Velumani T-ERS,HCLTech
    > <velumanit@hcl.com>; openbmc@lists.ozlabs.org
    > <openbmc@lists.ozlabs.org>; anoo@us.ibm.com <anoo@us.ibm.com>;
    > ojayanth@in.ibm.com <ojayanth@in.ibm.com>; gmills@linux.vnet.ibm.com
    > <gmills@linux.vnet.ibm.com>; ratagupt@linux.vnet.ibm.com
    > <ratagupt@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&amp;data=04%7C01%7CPriyatharshanP%40hcl.com%7Cef0c97b4694f44db53a508d87555c902%7C189de737c93a4f5a8b686f4ca9941912%7C0%7C0%7C637388358605381286%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=SWOdfla2MDRK4ostBDNzozQBpoyNdyvDNXPMpQo05Tk%3D&amp;reserved=0


[-- Attachment #2: Type: text/html, Size: 26690 bytes --]

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

[P. Priyatharshan]

[-- Attachment #1: Type: text/plain, Size: 17685 bytes --]

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@hcl.com>
Sent: 21 October 2020 10:57
To: Vijay Khemka <vijaykhemka@fb.com>; Adriana Kobylak <anoo@linux.ibm.com>
Cc: patrick@stwcx.xyz <patrick@stwcx.xyz>; openbmc@lists.ozlabs.org <openbmc@lists.ozlabs.org>; anoo@us.ibm.com <anoo@us.ibm.com>; ojayanth@in.ibm.com <ojayanth@in.ibm.com>; gmills@linux.vnet.ibm.com <gmills@linux.vnet.ibm.com>; Velumani T-ERS,HCLTech <velumanit@hcl.com>; ratagupt@linux.vnet.ibm.com <ratagupt@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@fb.com>
Sent: 21 October 2020 05:40
To: Adriana Kobylak <anoo@linux.ibm.com>; P. Priyatharshan <PriyatharshanP@hcl.com>
Cc: patrick@stwcx.xyz <patrick@stwcx.xyz>; openbmc@lists.ozlabs.org <openbmc@lists.ozlabs.org>; anoo@us.ibm.com <anoo@us.ibm.com>; ojayanth@in.ibm.com <ojayanth@in.ibm.com>; gmills@linux.vnet.ibm.com <gmills@linux.vnet.ibm.com>; Velumani T-ERS,HCLTech <velumanit@hcl.com>; ratagupt@linux.vnet.ibm.com <ratagupt@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@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@stwcx.xyz @Adriana Kobylak: Kindly share your
    > thoughts on this.
    >
    >  Thanks,
    >  Priyatharshan P
    >
    > -------------------------
    >
    > FROM: Vijay Khemka <vijaykhemka@fb.com>
    >  SENT: 16 October 2020 00:58
    >  TO: P. Priyatharshan <PriyatharshanP@hcl.com>; Adriana Kobylak
    > <anoo@linux.ibm.com>
    >  CC: openbmc@lists.ozlabs.org <openbmc@lists.ozlabs.org>;
    > anoo@us.ibm.com <anoo@us.ibm.com>; ojayanth@in.ibm.com
    > <ojayanth@in.ibm.com>; gmills@linux.vnet.ibm.com
    > <gmills@linux.vnet.ibm.com>; Velumani T-ERS,HCLTech
    > <velumanit@hcl.com>; ratagupt@linux.vnet.ibm.com
    > <ratagupt@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@lists.ozlabs.org> on
    > behalf of "P. Priyatharshan" <PriyatharshanP@hcl.com>
    >  DATE: Thursday, October 15, 2020 at 10:18 AM
    >  TO: Adriana Kobylak <anoo@linux.ibm.com>
    >  CC: "openbmc@lists.ozlabs.org" <openbmc@lists.ozlabs.org>,
    > "anoo@us.ibm.com" <anoo@us.ibm.com>, "ojayanth@in.ibm.com"
    > <ojayanth@in.ibm.com>, "gmills@linux.vnet.ibm.com"
    > <gmills@linux.vnet.ibm.com>, "Velumani T-ERS, HCLTech"
    > <velumanit@hcl.com>, "ratagupt@linux.vnet.ibm.com"
    > <ratagupt@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@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@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&amp;data=04%7C01%7CPriyatharshanP%40hcl.com%7Cef0c97b4694f44db53a508d87555c902%7C189de737c93a4f5a8b686f4ca9941912%7C0%7C0%7C637388358605381286%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=SWOdfla2MDRK4ostBDNzozQBpoyNdyvDNXPMpQo05Tk%3D&amp;reserved=0
    > [1]
    >
    > Thanks,
    >
    > Priyatharshan P
    >
    > -------------------------
    >
    > FROM: Adriana Kobylak <anoo@linux.ibm.com>
    >  SENT: 06 October 2020 03:11
    >  TO: P. Priyatharshan <PriyatharshanP@hcl.com>
    >  CC: Patrick Williams <patrick@stwcx.xyz>; Velumani T-ERS,HCLTech
    > <velumanit@hcl.com>; openbmc@lists.ozlabs.org
    > <openbmc@lists.ozlabs.org>; anoo@us.ibm.com <anoo@us.ibm.com>;
    > ojayanth@in.ibm.com <ojayanth@in.ibm.com>; gmills@linux.vnet.ibm.com
    > <gmills@linux.vnet.ibm.com>; ratagupt@linux.vnet.ibm.com
    > <ratagupt@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&amp;data=04%7C01%7CPriyatharshanP%40hcl.com%7Cef0c97b4694f44db53a508d87555c902%7C189de737c93a4f5a8b686f4ca9941912%7C0%7C0%7C637388358605381286%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=SWOdfla2MDRK4ostBDNzozQBpoyNdyvDNXPMpQo05Tk%3D&amp;reserved=0


[-- Attachment #2: Type: text/html, Size: 28569 bytes --]

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

[P. Priyatharshan]

[-- Attachment #1: Type: text/plain, Size: 19291 bytes --]

A Gentle Reminder..

Partrick/Adriyana/Vijay,

Kindly share your thoughts whether the below approach can be implemented.


>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@hcl.com>
Sent: 23 October 2020 19:04
To: Vijay Khemka <vijaykhemka@fb.com>; Adriana Kobylak <anoo@linux.ibm.com>
Cc: patrick@stwcx.xyz <patrick@stwcx.xyz>; openbmc@lists.ozlabs.org <openbmc@lists.ozlabs.org>; anoo@us.ibm.com <anoo@us.ibm.com>; ojayanth@in.ibm.com <ojayanth@in.ibm.com>; gmills@linux.vnet.ibm.com <gmills@linux.vnet.ibm.com>; Velumani T-ERS,HCLTech <velumanit@hcl.com>; ratagupt@linux.vnet.ibm.com <ratagupt@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@hcl.com>
Sent: 21 October 2020 10:57
To: Vijay Khemka <vijaykhemka@fb.com>; Adriana Kobylak <anoo@linux.ibm.com>
Cc: patrick@stwcx.xyz <patrick@stwcx.xyz>; openbmc@lists.ozlabs.org <openbmc@lists.ozlabs.org>; anoo@us.ibm.com <anoo@us.ibm.com>; ojayanth@in.ibm.com <ojayanth@in.ibm.com>; gmills@linux.vnet.ibm.com <gmills@linux.vnet.ibm.com>; Velumani T-ERS,HCLTech <velumanit@hcl.com>; ratagupt@linux.vnet.ibm.com <ratagupt@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@fb.com>
Sent: 21 October 2020 05:40
To: Adriana Kobylak <anoo@linux.ibm.com>; P. Priyatharshan <PriyatharshanP@hcl.com>
Cc: patrick@stwcx.xyz <patrick@stwcx.xyz>; openbmc@lists.ozlabs.org <openbmc@lists.ozlabs.org>; anoo@us.ibm.com <anoo@us.ibm.com>; ojayanth@in.ibm.com <ojayanth@in.ibm.com>; gmills@linux.vnet.ibm.com <gmills@linux.vnet.ibm.com>; Velumani T-ERS,HCLTech <velumanit@hcl.com>; ratagupt@linux.vnet.ibm.com <ratagupt@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@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@stwcx.xyz @Adriana Kobylak: Kindly share your
    > thoughts on this.
    >
    >  Thanks,
    >  Priyatharshan P
    >
    > -------------------------
    >
    > FROM: Vijay Khemka <vijaykhemka@fb.com>
    >  SENT: 16 October 2020 00:58
    >  TO: P. Priyatharshan <PriyatharshanP@hcl.com>; Adriana Kobylak
    > <anoo@linux.ibm.com>
    >  CC: openbmc@lists.ozlabs.org <openbmc@lists.ozlabs.org>;
    > anoo@us.ibm.com <anoo@us.ibm.com>; ojayanth@in.ibm.com
    > <ojayanth@in.ibm.com>; gmills@linux.vnet.ibm.com
    > <gmills@linux.vnet.ibm.com>; Velumani T-ERS,HCLTech
    > <velumanit@hcl.com>; ratagupt@linux.vnet.ibm.com
    > <ratagupt@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@lists.ozlabs.org> on
    > behalf of "P. Priyatharshan" <PriyatharshanP@hcl.com>
    >  DATE: Thursday, October 15, 2020 at 10:18 AM
    >  TO: Adriana Kobylak <anoo@linux.ibm.com>
    >  CC: "openbmc@lists.ozlabs.org" <openbmc@lists.ozlabs.org>,
    > "anoo@us.ibm.com" <anoo@us.ibm.com>, "ojayanth@in.ibm.com"
    > <ojayanth@in.ibm.com>, "gmills@linux.vnet.ibm.com"
    > <gmills@linux.vnet.ibm.com>, "Velumani T-ERS, HCLTech"
    > <velumanit@hcl.com>, "ratagupt@linux.vnet.ibm.com"
    > <ratagupt@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@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@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&amp;data=04%7C01%7CPriyatharshanP%40hcl.com%7Cef0c97b4694f44db53a508d87555c902%7C189de737c93a4f5a8b686f4ca9941912%7C0%7C0%7C637388358605381286%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=SWOdfla2MDRK4ostBDNzozQBpoyNdyvDNXPMpQo05Tk%3D&amp;reserved=0
    > [1]
    >
    > Thanks,
    >
    > Priyatharshan P
    >
    > -------------------------
    >
    > FROM: Adriana Kobylak <anoo@linux.ibm.com>
    >  SENT: 06 October 2020 03:11
    >  TO: P. Priyatharshan <PriyatharshanP@hcl.com>
    >  CC: Patrick Williams <patrick@stwcx.xyz>; Velumani T-ERS,HCLTech
    > <velumanit@hcl.com>; openbmc@lists.ozlabs.org
    > <openbmc@lists.ozlabs.org>; anoo@us.ibm.com <anoo@us.ibm.com>;
    > ojayanth@in.ibm.com <ojayanth@in.ibm.com>; gmills@linux.vnet.ibm.com
    > <gmills@linux.vnet.ibm.com>; ratagupt@linux.vnet.ibm.com
    > <ratagupt@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&amp;data=04%7C01%7CPriyatharshanP%40hcl.com%7Cef0c97b4694f44db53a508d87555c902%7C189de737c93a4f5a8b686f4ca9941912%7C0%7C0%7C637388358605381286%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=SWOdfla2MDRK4ostBDNzozQBpoyNdyvDNXPMpQo05Tk%3D&amp;reserved=0


[-- Attachment #2: Type: text/html, Size: 32218 bytes --]

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

[Adriana Kobylak]

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@hcl.com>
>  SENT: 23 October 2020 19:04
>  TO: Vijay Khemka <vijaykhemka@fb.com>; Adriana Kobylak
> <anoo@linux.ibm.com>
>  CC: patrick@stwcx.xyz <patrick@stwcx.xyz>; openbmc@lists.ozlabs.org
> <openbmc@lists.ozlabs.org>; anoo@us.ibm.com <anoo@us.ibm.com>;
> ojayanth@in.ibm.com <ojayanth@in.ibm.com>; gmills@linux.vnet.ibm.com
> <gmills@linux.vnet.ibm.com>; Velumani T-ERS,HCLTech
> <velumanit@hcl.com>; ratagupt@linux.vnet.ibm.com
> <ratagupt@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@hcl.com>
>  SENT: 21 October 2020 10:57
>  TO: Vijay Khemka <vijaykhemka@fb.com>; Adriana Kobylak
> <anoo@linux.ibm.com>
>  CC: patrick@stwcx.xyz <patrick@stwcx.xyz>; openbmc@lists.ozlabs.org
> <openbmc@lists.ozlabs.org>; anoo@us.ibm.com <anoo@us.ibm.com>;
> ojayanth@in.ibm.com <ojayanth@in.ibm.com>; gmills@linux.vnet.ibm.com
> <gmills@linux.vnet.ibm.com>; Velumani T-ERS,HCLTech
> <velumanit@hcl.com>; ratagupt@linux.vnet.ibm.com
> <ratagupt@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@fb.com>
>  SENT: 21 October 2020 05:40
>  TO: Adriana Kobylak <anoo@linux.ibm.com>; P. Priyatharshan
> <PriyatharshanP@hcl.com>
>  CC: patrick@stwcx.xyz <patrick@stwcx.xyz>; openbmc@lists.ozlabs.org
> <openbmc@lists.ozlabs.org>; anoo@us.ibm.com <anoo@us.ibm.com>;
> ojayanth@in.ibm.com <ojayanth@in.ibm.com>; gmills@linux.vnet.ibm.com
> <gmills@linux.vnet.ibm.com>; Velumani T-ERS,HCLTech
> <velumanit@hcl.com>; ratagupt@linux.vnet.ibm.com
> <ratagupt@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@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@stwcx.xyz @Adriana Kobylak: Kindly share
> your
>  > thoughts on this.
>  >
>  > Thanks,
>  > Priyatharshan P
>  >
>  > -------------------------
>  >
>  > FROM: Vijay Khemka <vijaykhemka@fb.com>
>  > SENT: 16 October 2020 00:58
>  > TO: P. Priyatharshan <PriyatharshanP@hcl.com>; Adriana Kobylak
>  > <anoo@linux.ibm.com>
>  > CC: openbmc@lists.ozlabs.org <openbmc@lists.ozlabs.org>;
>  > anoo@us.ibm.com <anoo@us.ibm.com>; ojayanth@in.ibm.com
>  > <ojayanth@in.ibm.com>; gmills@linux.vnet.ibm.com
>  > <gmills@linux.vnet.ibm.com>; Velumani T-ERS,HCLTech
>  > <velumanit@hcl.com>; ratagupt@linux.vnet.ibm.com
>  > <ratagupt@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@lists.ozlabs.org>
> on
>  > behalf of "P. Priyatharshan" <PriyatharshanP@hcl.com>
>  > DATE: Thursday, October 15, 2020 at 10:18 AM
>  > TO: Adriana Kobylak <anoo@linux.ibm.com>
>  > CC: "openbmc@lists.ozlabs.org" <openbmc@lists.ozlabs.org>,
>  > "anoo@us.ibm.com" <anoo@us.ibm.com>, "ojayanth@in.ibm.com"
>  > <ojayanth@in.ibm.com>, "gmills@linux.vnet.ibm.com"
>  > <gmills@linux.vnet.ibm.com>, "Velumani T-ERS, HCLTech"
>  > <velumanit@hcl.com>, "ratagupt@linux.vnet.ibm.com"
>  > <ratagupt@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@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@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&amp;data=04%7C01%7CPriyatharshanP%40hcl.com%7Cef0c97b4694f44db53a508d87555c902%7C189de737c93a4f5a8b686f4ca9941912%7C0%7C0%7C637388358605381286%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=SWOdfla2MDRK4ostBDNzozQBpoyNdyvDNXPMpQo05Tk%3D&amp;reserved=0
> [1]
>  > [1]
>  >
>  > Thanks,
>  >
>  > Priyatharshan P
>  >
>  > -------------------------
>  >
>  > FROM: Adriana Kobylak <anoo@linux.ibm.com>
>  > SENT: 06 October 2020 03:11
>  > TO: P. Priyatharshan <PriyatharshanP@hcl.com>
>  > CC: Patrick Williams <patrick@stwcx.xyz>; Velumani T-ERS,HCLTech
>  > <velumanit@hcl.com>; openbmc@lists.ozlabs.org
>  > <openbmc@lists.ozlabs.org>; anoo@us.ibm.com <anoo@us.ibm.com>;
>  > ojayanth@in.ibm.com <ojayanth@in.ibm.com>;
> gmills@linux.vnet.ibm.com
>  > <gmills@linux.vnet.ibm.com>; ratagupt@linux.vnet.ibm.com
>  > <ratagupt@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&amp;data=04%7C01%7CPriyatharshanP%40hcl.com%7Cef0c97b4694f44db53a508d87555c902%7C189de737c93a4f5a8b686f4ca9941912%7C0%7C0%7C637388358605381286%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=SWOdfla2MDRK4ostBDNzozQBpoyNdyvDNXPMpQo05Tk%3D&amp;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&amp;amp;data=04%7C01%7CPriyatharshanP%40hcl.com%7Cef0c97b4694f44db53a508d87555c902%7C189de737c93a4f5a8b686f4ca9941912%7C0%7C0%7C637388358605381286%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;amp;sdata=SWOdfla2MDRK4ostBDNzozQBpoyNdyvDNXPMpQo05Tk%3D&amp;amp;reserved=0

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

[Patrick Williams]

[-- Attachment #1: Type: text/plain, Size: 615 bytes --]

On Fri, Oct 30, 2020 at 01:52:32PM -0500, Adriana Kobylak wrote:
> I'd suggest filling up a design document template[1].

Agreed.  I tried looking back at the discussion and I'm not sure what
the remaining open issues are here to give additional feedback on.  A 
design proposal and summary of the outstanding questions would help
give direction to where we still need solutions before you can proceed.

Feel free to spell out "Open Issues: ..." right in a design proposal and
we can work through that in review or defer back to the mailing list for
discussion on the specifics.

-- 
Patrick Williams

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

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

[Adriana Kobylak]

On 2020-11-03 15:01, Patrick Williams wrote:
> On Fri, Oct 30, 2020 at 01:52:32PM -0500, Adriana Kobylak wrote:
>> I'd suggest filling up a design document template[1].
> 
> Agreed.  I tried looking back at the discussion and I'm not sure what
> the remaining open issues are here to give additional feedback on.  A
> design proposal and summary of the outstanding questions would help
> give direction to where we still need solutions before you can proceed.
> 
> Feel free to spell out "Open Issues: ..." right in a design proposal 
> and
> we can work through that in review or defer back to the mailing list 
> for
> discussion on the specifics.

For anyone interested, design doc: 
https://gerrit.openbmc-project.xyz/c/openbmc/docs/+/37950