Open Stack

On Tue, Mar 26, 2019 at 09:21:06AM +0000, Hunt, James O wrote:
> Le mar. 26 mars 2019 à 08:02, Stefan Hajnoczi <stefanha at redhat.com> a
> écrit :
> > On Mon, Mar 25, 2019 at 04:42:17PM +0000, Venegas Munoz, Jose Carlos wrote:
> > Lokesh: Out of the various options for building Kata images (initramfs
> > vs disk image, systemd vs agent), which ones are friendliest for Fedora
> > packaging?
> >
> 
> There may be an alternative solution to the ongoing issue of packaging
> binaries images...
> 
> - Kata needs a binary rootfs image and a binary kernel image to boot the
> hypervisor. Once booted, the user's chosen (binary) disk image will be made
> available for the workload (you might be able to see where this is going...
> :)
> - Our OBS packaging currently packages images and kernels as a convenience
> to users.
> - Container managers like Docker also require binary images. But those
> images are not packaged - they are downloaded on demand ("docker pull").
> - This leads to a potential solution to the packaging blocker: Kata could
> be packaged without any binary assets.
> - If the binaries were not packaged, an additional step would be required
> before a Kata container could be created, something like [2]:
> 
>     $ sudo kata-runtime pull [all-assets|image|initrd|kernel]
> 
> There are complications with this concept though, including:
> 
> - Where would we host such assets?
> - How would the kernel be handled?
> - How would the system determine which type of image to download?
> - How would updates to these assets be handled? We need to avoid / minimise
> the "stale container" scenario [3].

I am not familiar enough with Fedora and Debian packaging policies to
know whether this approach is acceptable under those policies.  I like
it though because it gives the Kata Community control over producing and
updating images without complicating package maintainers' lives.

From a user perspective it would be nice not to know or worry about the
sandbox kernel & rootfs.  That's an implementation detail of Kata
Containers.

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/20190327/92a6ebf5/attachment.sig>