Open Stack

I played around with a prototype a long time ago with getting clear containers deployable by container. Then you could use a kubernetes daemonset to deploy/manage additional runtimes.

If I remember correctly, I failed at the time because crio was not reenterent (may be now). But since then I've also learned of nsenter and think that could be used to solve the problem, and do it in a much lighter weight way.

Has anyone considered this use case recently?

Thanks,
Kevin
________________________________________
From: Stefan Hajnoczi [stefanha at redhat.com]
Sent: Wednesday, March 27, 2019 9:05 AM
To: Hunt, James O
Cc: Lokesh Mandvekar; kata-dev
Subject: Re: [kata-dev] kata image types compared

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