<div dir="ltr"><div dir="ltr"><div class="gmail_default" style="font-size:small">Hi Stefan,</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Le mar. 26 mars 2019 à 08:02, Stefan Hajnoczi <<a href="mailto:stefanha@redhat.com">stefanha@redhat.com</a>> a écrit :<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Mon, Mar 25, 2019 at 04:42:17PM +0000, Venegas Munoz, Jose Carlos wrote:<br>
> That is a good point.<br>
> <br>
> Working with current kata packages (in OBS) and with Lokesh from Fedora this not a very distro friendly process.<br>
> <br>
> 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).<br>
> <br>
> I see the following  requirements  for rootfs creation point + packaging  limitations.<br>
> <br>
> - rootfs creation should work without network access<br>
> - Not need to rely on a package manager (like populate a directory with dnf)<br>
> <br>
> To handle this we probably have two options:<br>
> <br>
> - Create roots with a tool like Dracut ( If somebody has some experience with it feel free to open an issue to talk about it)<br>
> - Remove systemd depencies, just have as rootfs dependency: agent, ipables  <name other random binaries we need in the future).<br>
>     - The binaries need to be static as requirement: with this rootfs creation is just copy binaries to a directory.<br>
>     - If binaries are not static we can parse ldd output and copy the right libs to the rootfs directory.<br>
>     - See <a href="https://github.com/kata-containers/osbuilder/issues/259" rel="noreferrer" target="_blank">https://github.com/kata-containers/osbuilder/issues/259</a> for more information about this.<br>
<br>
I have CCed Lokesh for Fedora-specific requirements for Kata images:<br>
<a href="https://github.com/kata-containers/documentation/wiki/Kata-images" rel="noreferrer" target="_blank">https://github.com/kata-containers/documentation/wiki/Kata-images</a></blockquote><div><br></div><div><div class="gmail_default" style="font-size:small">This page was originally intended simply to summarise the differences between image options. However, I'm really glad you've brought up the important and ongoing issue of distro packaging. I've tried to summarise that in [1], but maybe that too needs to be surfaced by putting it into a wiki page of its own.</div><div class="gmail_default" style="font-size:small"><br></div></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br>
<br>
Lokesh: Out of the various options for building Kata images (initramfs<br>
vs disk image, systemd vs agent), which ones are friendliest for Fedora<br>
packaging?<br></blockquote><div><br></div><div><div class="gmail_default" style="font-size:small">There may be an alternative solution to the ongoing issue of packaging binaries images...</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">- 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... :)</div></div><div>- Our OBS packaging currently packages images and kernels as a convenience to users<span class="gmail_default" style="font-size:small">.</span><br></div><div><div class="gmail_default" style="font-size:small">- Container managers like Docker also require binary images. But those images are not packaged - they are downloaded on demand ("docker pull").</div><div class="gmail_default" style="font-size:small">- This leads to a potential solution to the packaging blocker: Kata could be packaged without any binary assets.</div><div class="gmail_default" style="font-size:small">- If the binaries were not packaged, an additional step would be required before a Kata container could be created, something like [2]:<br></div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">    $ sudo kata-runtime pull [all-assets|image|initrd|kernel]<br></div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">There are complications with this concept though, including:<br></div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">- Where would we host such assets?</div><div class="gmail_default" style="font-size:small">- How would the kernel be handled?</div><div class="gmail_default" style="font-size:small">- How would the system determine which type of image to download?</div><div class="gmail_default" style="font-size:small">- How would updates to these assets be handled? We need to avoid / minimise the "stale container" scenario [3].</div><div class="gmail_default" style="font-size:small"><br></div></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
Is anyone in touch with Debian packagers who could provide input?<br></blockquote><div><br></div><div><div class="gmail_default" style="font-size:small">As shown on [1], we're still looking for Debian volunteers, so if anyone is keen...? :)</div></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
Stefan<br>
</blockquote></div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">Cheers,</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">James</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">[1] - <a href="https://github.com/kata-containers/packaging/issues/6#issuecomment-453940053">https://github.com/kata-containers/packaging/issues/6#issuecomment-453940053</a></div><div class="gmail_default" style="font-size:small">[2] - If that wasn't done, the runtime would select suitable defaults when "kata-runtime create" was invoked. That would of course delay the creation of the initial Kata container but would be similar to how, say, Docker works if you "docker run" without a previous "docker pull".</div><div class="gmail_default" style="font-size:small">[3] - <a href="https://github.com/clearcontainers/runtime/wiki/Stale-containers">https://github.com/clearcontainers/runtime/wiki/Stale-containers</a></div><div class="gmail_default" style="font-size:small"><br></div><div><span style="font-family:monospace,monospace;color:rgb(136,136,136)">---</span><br></div><div dir="ltr" class="gmail_signature"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><a href="https://katacontainers.io/" style="color:rgb(17,85,204);font-family:monospace,monospace" target="_blank">https://katacontainers.io/</a><span style="color:rgb(136,136,136);font-family:monospace,monospace"> | <a href="https://github.com/clearcontainers" target="_blank">https://github.com/kata-containers</a></span><font color="#888888"><span style="font-family:monospace,monospace"><span style="font-family:monospace,monospace"><br></span></span></font></div><div dir="ltr"><font color="#888888"><font face="monospace, monospace">Open Source Technology Center</font><br><font face="monospace, monospace">Intel Corporation (UK) Ltd. - Co. Reg. #1134945 - Pipers Way, Swindon SN3 1RJ.</font></font><br></div></div></div></div></div></div></div></div></div></div>