BMC flows in SONiC #2062
BMC flows in SONiC #2062
Conversation
|
/azp run |
|
No pipelines are associated with this pull request. |
yuazhe
requested review from
eddyk-nvidia,
judyjoseph,
keboliu,
liat-grozovik,
prgeor and
rlhui
|
/azp run |
|
No pipelines are associated with this pull request. |
|
/azp run |
|
No pipelines are associated with this pull request. |
yuazhe
force-pushed
the
master_bmc_hld
branch
from
88cb03d to
58f1fda
Compare
|
/azp run |
|
No pipelines are associated with this pull request. |
yuazhe
force-pushed
the
master_bmc_hld
branch
from
58f1fda to
8efb1bc
Compare
|
/azp run |
|
No pipelines are associated with this pull request. |
yuazhe
force-pushed
the
master_bmc_hld
branch
from
8efb1bc to
aae88ad
Compare
|
/azp run |
|
No pipelines are associated with this pull request. |
yuazhe
force-pushed
the
master_bmc_hld
branch
from
aae88ad to
85fe3b2
Compare
|
/azp run |
|
No pipelines are associated with this pull request. |
| Board Management Controller (BMC) is a specialized microcontroller embedded on a motherboard. It manages the interface between system management software and hardware. BMC provides out-of-band management capabilities, allowing administrators to monitor and manage hardware remotely. | ||
| OpenBMC is an open-source project that provides a Linux-based firmware stack for Board Management Controllers (BMCs). It implements the Redfish standard, allowing for standardized and secure remote management of server hardware. In essence, OpenBMC serves as the software that runs on BMC hardware, utilizing the Redfish API to facilitate efficient hardware management. | ||
| Redfish is a standard for managing and interacting with hardware in a datacenter, designed to be simple, secure, and scalable. It works with BMC to provide a RESTful API for remote management of servers. Together, Redfish and BMC enable efficient and standardized hardware management. | ||
| In summary, NOS will deal with BMC through the redfish RESTful API. |
There was a problem hiding this comment.
By "NOS will deal with BMC", did you mean NOS managing the below responsibilities?
- maintenance via FPD upgrades.
- debug BMC via showtech.
- BMC info access via APIs/CLIs.
Mainly asking in the context of ensuring the use cases being addressed in this doc.
There was a problem hiding this comment.
for 1, the upgrade of bmc is controlled by nos, but whether it will through FPD is arguable.
for 2,3 yes.
| The implementation is straightforward: SONiC will incorporate a Redfish client as the underlying infrastructure to support the BMC action. This Redfish client object is implemented and initialized at runtime by SONiC itself. | ||
|  | ||
|
|
||
| ## 3. BMC ip address initialization |
There was a problem hiding this comment.
I assume this section is setting an interface on the host (running the NOS) with static information based on configuration in a json file. This interface will then be used to communicate with the BMC.
If above is the case, do we assume the BMC stack provided by the vendor will be responsible for setting the corresponding interface to communicate with the host/NOS?
There was a problem hiding this comment.
correct, and yes the vendor is responsible for setting the interface between bmc/nos
|
|
||
| ## 3. BMC firmware upgrade flow | ||
|
|
||
| It requires a new ComponenetBMC object to be added to the component.py |
There was a problem hiding this comment.
- OpenBMC has a Uboot and FIT partition. Do we assume the firmware upgrade workflow for BMC is the entire flash and not individual components?
- Do we also need to support NOS abstraction (CLI/API) for upgrading the Alternate BMC Flash in case of Dual Flash scenarios?
There was a problem hiding this comment.
for 1, yes, I'm talking about an entire flash
for 2, I'm not sure about the question, you mean we have 2 bmc image and want to choose between them?
There was a problem hiding this comment.
By (2) I meant, in certain cases, the hardware running OpenBMC comes with support for dual flash (Primary and Golden/Alternate) which are both programmed with OpenBMC images. The image from alternate flash boots when the Primary gets corrupted or unable to boot an image.
Most boards (Including eval boards like ast2600) that run OpenBMC support dual flash configurations as a standard. But this will be BMC hardware/vendor specific.
There was a problem hiding this comment.
at this stage I suggest to not include this functionality to keep the simplicity
|
|
||
| ## 2. BMC flows in SONiC | ||
| The implementation is straightforward: SONiC will incorporate a Redfish client as the underlying infrastructure to support the BMC action. This Redfish client object is implemented and initialized at runtime by SONiC itself. | ||
|  |
There was a problem hiding this comment.
Is there a recommendation for the kind of authentication that will be used by the redfish client from the NOS to use the RESTFUL APIs? I'm assuming vendors will move away from default username and passwords for OpenBMC.
Please ignore this comment if its outside the scope of this document.
There was a problem hiding this comment.
Redfish provides HTTP basic authentication using the Authorization header in an HTTPS request, in my opinion, the way of generating the password to replace the default one is vendor specific
Signed-off-by: Yuanzhe, Liu <[email protected]>
yuazhe
force-pushed
the
master_bmc_hld
branch
from
85fe3b2 to
636ba11
Compare
|
/azp run |
|
No pipelines are associated with this pull request. |
yuazhe
requested review from
Junchao-Mellanox and
gbala88
and removed request for
gbala88
|
|
||
| After community review, there are two improvements that will be made in the 202605 branch: | ||
|
|
||
| 1. The Redfish client will be added to the platform common API, providing support for these APIs, and it will be easier to extend for vendor-specific use. |
There was a problem hiding this comment.
we need to have this as a common library not a vendor specific library.
6 participants
No description provided.