On Tue, Mar 26, 2019 at 09:21:06AM +0000, Hunt, James O wrote:
Le mar. 26 mars 2019 à 08:02, Stefan Hajnoczi <stefanha@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