What do you want in a package manager?

What do you want in a package manager?

[Nancy Yuen]

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

I'm looking into package management for BMCs in our fleet.  I'm wondering
who else is interested in this, does it make sense for OpenBMC.  What kind
of features are important?  What kind of package format (rpm, deb,
something else)?

We have a distributed system dictating versions of software (BIOS, OS,
userspace packages, other firmware) which should be on a particular machine
(based a machine's characteristics like type, owner, etc). So our use case
has the BMC take a list of packages to be installed, natively installing
the packages on the BMC. Packages must be signed and verified
during installation.  There is also the concept of deviation checking.  If
the files for a package or some parts of the file system deviates from
what's expected, it triggers some kind of repair flow.

----------
Nancy

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

Re: What do you want in a package manager?

[Patrick Williams]

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

On Tue, Jul 21, 2020 at 12:57:00AM -0700, Nancy Yuen wrote:
> I'm looking into package management for BMCs in our fleet.  I'm wondering
> who else is interested in this, does it make sense for OpenBMC.  What kind
> of features are important?  What kind of package format (rpm, deb,
> something else)?

We've similarly started playing with package management at Facebook.
One of the reasons for us doing it is that we still have Python
installed in the image and are running out of space, so we're moving
some of the debug tools into packages that can be side-loaded as needed.
We've also implemented 'ptest', which allows you to create packages
containing your unit tests and run them on a real machine.

We found that we had to switch to ipkg instead of rpm because the extra
things rpm needed were too big to fit.  I recall it was on the order of
5MB of content needed to make rpm work and ipkg was almost free. [1]

One issue you'll want to be aware of, that many of our recipes have, is
that they often are missing:

    PACKAGE_ARCH = "${MACHINE_ARCH}"

This causes the package to be specified as relevant for a generic ARM
system, matching the architecture revision of your underlying AST2xxx
chip, rather than your particular machine.  Any package which can be
customized for a particular machine (such as by machine-specific compile
flags, or YAML/JSON files) should have the above variable set so that a
package compiled for Witherspoon cannot be installed onto a Zaius.

If you look under your Yocto build tree under `tmp/work` you'll see
`arm1176jzs-openbmc-linux-gnueabi` and
`witherspoon-openbmc-linux-gnueabi`.  I suspect at least most of the
phosphor-* packages under the arm1176jzs subdirectory are likely candidates
for having this PACKAGE_ARCH fixed.  We might want to simply add it to
any '.bbappend' we do in a machine layer.

1. https://github.com/facebook/openbmc/commit/43430d38dfd0e5557f96940547594e01373f863e

-- 
Patrick Williams

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

Re: What do you want in a package manager?

[Nancy Yuen]

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

On Tue, Jul 21, 2020 at 8:17 AM Patrick Williams <patrick@stwcx.xyz> wrote:

> On Tue, Jul 21, 2020 at 12:57:00AM -0700, Nancy Yuen wrote:
> > I'm looking into package management for BMCs in our fleet.  I'm wondering
> > who else is interested in this, does it make sense for OpenBMC.  What
> kind
> > of features are important?  What kind of package format (rpm, deb,
> > something else)?
>
> We've similarly started playing with package management at Facebook.
> One of the reasons for us doing it is that we still have Python
> installed in the image and are running out of space, so we're moving
> some of the debug tools into packages that can be side-loaded as needed.
> We've also implemented 'ptest', which allows you to create packages
> containing your unit tests and run them on a real machine.
>

Our first use case is loading fw packages for other system components
managed by the BMC, so not code directly run by the BMC.  But I can see it
extending to other things, daemons we want to update independing etc.  We
are also running out of space, exploring secondary storage options.  I
think that's primarily where the package manager will be managing packages
in Google systems.  The BMC flash will have a basic core firmware image,
and load other packages from secondary storage.

How far have you gotten with package management?  What have you considered?


>
> We found that we had to switch to ipkg instead of rpm because the extra
> things rpm needed were too big to fit.  I recall it was on the order of
> 5MB of content needed to make rpm work and ipkg was almost free. [1]
>

Today Google has a custom package format but I want to see what other
options make sense in the wider OpenBMC community.  I'm not familiar with
ipkg so I'll take a look.


> One issue you'll want to be aware of, that many of our recipes have, is
> that they often are missing:
>
>     PACKAGE_ARCH = "${MACHINE_ARCH}"
>
> This causes the package to be specified as relevant for a generic ARM
> system, matching the architecture revision of your underlying AST2xxx
> chip, rather than your particular machine.  Any package which can be
> customized for a particular machine (such as by machine-specific compile
> flags, or YAML/JSON files) should have the above variable set so that a
> package compiled for Witherspoon cannot be installed onto a Zaius.
>
> If you look under your Yocto build tree under `tmp/work` you'll see
> `arm1176jzs-openbmc-linux-gnueabi` and
> `witherspoon-openbmc-linux-gnueabi`.  I suspect at least most of the
> phosphor-* packages under the arm1176jzs subdirectory are likely candidates
> for having this PACKAGE_ARCH fixed.  We might want to simply add it to
> any '.bbappend' we do in a machine layer.
>

I wasn't aware of that, thanks!


>
> 1.
> https://github.com/facebook/openbmc/commit/43430d38dfd0e5557f96940547594e01373f863e
>
> --
> Patrick Williams
>


----------
Nancy

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

Re: What do you want in a package manager?

[Vijay Khemka]

On 7/21/20, 8:23 AM, "openbmc on behalf of Patrick Williams" <openbmc-bounces+vijaykhemka=fb.com@lists.ozlabs.org on behalf of patrick@stwcx.xyz> wrote:

    On Tue, Jul 21, 2020 at 12:57:00AM -0700, Nancy Yuen wrote:
    > I'm looking into package management for BMCs in our fleet.  I'm wondering
    > who else is interested in this, does it make sense for OpenBMC.  What kind
    > of features are important?  What kind of package format (rpm, deb,
    > something else)?

    We've similarly started playing with package management at Facebook.
    One of the reasons for us doing it is that we still have Python
    installed in the image and are running out of space, so we're moving
    some of the debug tools into packages that can be side-loaded as needed.
    We've also implemented 'ptest', which allows you to create packages
    containing your unit tests and run them on a real machine.

    We found that we had to switch to ipkg instead of rpm because the extra
    things rpm needed were too big to fit.  I recall it was on the order of
    5MB of content needed to make rpm work and ipkg was almost free. [1]

    One issue you'll want to be aware of, that many of our recipes have, is
    that they often are missing:

        PACKAGE_ARCH = "${MACHINE_ARCH}"

    This causes the package to be specified as relevant for a generic ARM
    system, matching the architecture revision of your underlying AST2xxx
    chip, rather than your particular machine.  Any package which can be
    customized for a particular machine (such as by machine-specific compile
    flags, or YAML/JSON files) should have the above variable set so that a
    package compiled for Witherspoon cannot be installed onto a Zaius.

    If you look under your Yocto build tree under `tmp/work` you'll see
    `arm1176jzs-openbmc-linux-gnueabi` and
    `witherspoon-openbmc-linux-gnueabi`.  I suspect at least most of the
    phosphor-* packages under the arm1176jzs subdirectory are likely candidates
    for having this PACKAGE_ARCH fixed.  We might want to simply add it to
    any '.bbappend' we do in a machine layer.
Yes this is true, almost every package goes in this except kernel. We should
have a fix for this.

    1. https://github.com/facebook/openbmc/commit/43430d38dfd0e5557f96940547594e01373f863e

    -- 
    Patrick Williams

Re: What do you want in a package manager?

[Adriana Kobylak]

On 2020-07-21 02:57, Nancy Yuen wrote:
> I'm looking into package management for BMCs in our fleet.  I'm
> wondering who else is interested in this, does it make sense for
> OpenBMC.  What kind of features are important?  What kind of package
> format (rpm, deb, something else)?
> 
> We have a distributed system dictating versions of software (BIOS, OS,
> userspace packages, other firmware) which should be on a particular
> machine (based a machine's characteristics like type, owner, etc). So
> our use case has the BMC take a list of packages to be installed,
> natively installing the packages on the BMC.

Something around that area is this new recipe[1] to add a host fw image 
to the BMC image at build time[2]. It'd be useful to have a manager that 
would use different recipes to build a final image based on different 
pieces.

> Packages must be signed
> and verified during installation.

To support the new image file provided by the host fw recipe, the 
bmc-code-mgmt-repo added the concept of 'optional images'[3] that would 
allow additional files to be included in the code update tarball and 
enforce signature verification on them. Maybe that can be used/expanded 
as we add support for additional packages.

> There is also the concept of
> deviation checking.  If the files for a package or some parts of the
> file system deviates from what's expected, it triggers some kind of
> repair flow.
> 
> ----------
> Nancy

1. 
https://github.com/openbmc/meta-phosphor/commit/39b1ff0dcd12f15dc651aa20cb85cdec903cb5de
2. https://gerrit.openbmc-project.xyz/c/openbmc/meta-aspeed/+/34618
3. 
https://github.com/openbmc/phosphor-bmc-code-mgmt/commit/73609bb51c8c43d471ba373317455d3cbe5c5c32