OpenBMC Upstream Reference System(s)
jrey at linux.vnet.ibm.com
Thu Dec 13 10:04:53 AEDT 2018
On 2018-12-10 13:05, Andrew Geissler wrote:
> One thing that has come up a few times, and was touched on in last
> Infrastructure workgroup (and todays community meeting), was what is
> community reference system(s)? i.e. What do we as a community test
> and guarantee works when we do a tag or release?
> If you look at something like https://openpower.xyz/job/openbmc-build/
> will see a variety of systems. Romulus is put through QEMU CI and
> Witherspoon, is put through HW CI currently. This list has been mostly
> by IBM, and so it brings up the question of what's our future plan
> First, what's the criteria for adding a system to officially being
> supported by
> the upstream community?
> - Covers as much OpenBMC function as possible?
> - Is on hardware that anyone can easily (and cheaply) get their hands
> - Has consistent upstream support and a person or company to support HW
At today's Infrastructure Workgroup I mentioned four levels of machine
support, where each level builds on the previous level, providing a path
to get more support for your machine. Here are my ideas, provided for
1. Source code - The machine has a repo in the openbmc organization.
DETAILS: The machine has an github.com/openbmc/meta-MACHINE repository
with a BitBake layer configuration which defines the meta-phosphor layer
and can build the obmc-phosphor-image. Expectations are that the code
builds and is maintained, e.g., maintainers respond to a call for
2. CI Builds - The openbmc-phosphor-image is built for the machine as
part of Jenkins CI testing, and maintainers address failures in their
layer. DETAILS: Build failures will result in a -1 Gerrit code review
score, which may prevent merging. Because the image costs CPU cycles to
build (one build per Gerrit patch set), is there an expectation that the
team behind the machine provides a similar amount of value to the
project? Examples: donate the use of servers to the project, or have
significant contributions to common functions, for example,
3. CI Tested - The machine is booted and tested as part of the Jenkins
CI testing, and maintainers address failures in their layer. DETAILS:
Testcase failures will result in a -1 Gerrit code review score, which
may prevent merging. The expectation is the sponsoring organization
will donate the use of physical hardware which they may host behind
their company firewall.
4. Reference platform - The machine is an OpenBMC reference platform.
DETAILS: I assume the TSC would maintain the list of reference platforms
based on community input. I see one criterion (CI Tested) and several
factors in the TSC's decision:
- The machine has active development (git commits) and good support (CI
failures are addressed).
- The machine can be obtained, e.g., purchased.
- The machine has a simulator, e.g., QEMU.
- The machine is different than existing reference platforms.
What value is being a reference platform beyond being tested by CI?
> The witherspoon and romulus systems definitely are well supported by
> IBM in
> the upstream community but they are not all that cheap. There was a
> pi port out there that would be cheap and easy to get access to but not
> as much OpenBMC function. There's something like
> https://www.raptorcs.com/content/TLSDS3/intro.html which is a bit more
> accessible but I don't believe the code has been upstreamed.
> One point made in last weeks Infrastructure workgroup is we should
> for a minimum amount of hardware that covers as much function as
> So a matrix of some sort that covers our major functional areas. In
> having a system on the upstream support list is like getting your code
> once in, you have a guarantee that all future code will support it, so
> this is more of a community reward to get your system on the list?
> Just throwing ideas out there, input and ideas appreciated.
More information about the openbmc