Open Stack

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 455 bytes
Desc: not available
URL: <http://lists.katacontainers.io/pipermail/kata-dev/attachments/20190325/0f9872e8/attachment.sig>