Open Stack

That is a good point.

Working with current kata packages (in OBS) and with Lokesh from Fedora this not a very distro friendly process.

In my mind remove systemd could simplify the rootfs creation, ideally features needed by the agent would be implemented there ( I know sometimes we just prefer to use an existing binary for that).

I see the following  requirements  for rootfs creation point + packaging  limitations.

- rootfs creation should work without network access
- Not need to rely on a package manager (like populate a directory with dnf)

To handle this we probably have two options:

- Create roots with a tool like Dracut ( If somebody has some experience with it feel free to open an issue to talk about it)
- Remove systemd depencies, just have as rootfs dependency: agent, ipables  <name other random binaries we need in the future).
    - The binaries need to be static as requirement: with this rootfs creation is just copy binaries to a directory.
    - If binaries are not static we can parse ldd output and copy the right libs to the rootfs directory.
    - See https://github.com/kata-containers/osbuilder/issues/259 for more information about this.

-
Carlos

-----Original Message-----
From: Stefan Hajnoczi [mailto:stefanha at redhat.com] 
Sent: Monday, March 25, 2019 10:28 AM
To: Hunt, James O <james.o.hunt at intel.com>
Cc: kata-dev <kata-dev at lists.katacontainers.io>
Subject: Re: [kata-dev] kata image types compared

On Fri, Mar 22, 2019 at 09:30:18AM +0000, Hunt, James O wrote:
> As these topics are related, we've created a wiki page to try to 
> summarise the above including advantages and disadvantages of each 
> approach (image compared with initrd, agent as init and systemd as init):
> 
> https://github.com/kata-containers/documentation/wiki/Kata-images
> 
> Please contribute to this page to allow us all to get the best 
> possible picture of use-cases, features, limitations and benefits of each option.

A missing use case is packaging Kata Containers for Linux distributions.
Kata isn't available in the Debian or Fedora package collections yet.

The image is one of the tricky issues that packagers need to solve.  I think that the current solutions are developer-friendly but not packaging-friendly.

As Kata matures, the packaging use case will become more important so that end-users can "apt install kata-containers" or "dnf install kata-containers".  Although some users will continue to install the latest and greatest directly from kata-containers.io, having packages supported by distributions ensures that they integrate into the rest of the system (e.g. Docker, CRI-O) easily and with fewer steps than assembling a stack from multiple third-parties.

Each distro has kernel update policies, licensing considerations, etc that affect how Kata Containers can be packaged in a supportable way.
Taking at Debian and Fedora requirements on board when comparing image options would help.

Discussing this use case and optimizing for it would be important if there is general agreement that getting Kata Containers into Linux distributions is a priority.

Stefan