
<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><meta http-equiv="Content-Type" content="text/html; charset=utf-8" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><br class=""><div class=""><br class=""><blockquote type="cite" class=""><div class="">On 12 Aug 2020, at 02:42, Eric Ernst <<a href="mailto:eric.g.ernst@gmail.com" class="">eric.g.ernst@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" style="caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: 18px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none;" class=""><div dir="ltr" class="">Sorry I missed the call this morning. My takes below.<div class=""><br class=""></div><div class="">--Eric</div></div><br class=""><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Aug 11, 2020 at 2:09 PM Fabiano Fidêncio <<a href="mailto:fidencio@redhat.com" class="">fidencio@redhat.com</a>> wrote:<br class=""></div><blockquote class="gmail_quote" style="margin: 0px 0px 0px 0.8ex; border-left-width: 1px; border-left-style: solid; border-left-color: rgb(204, 204, 204); padding-left: 1ex;">Folks!<br class=""><br class="">We have discussed during this week's Architecture's meeting what could<br class="">be a plan for the future with regards to packaging and I'd like to<br class="">drop a suggestion here and then have it discussed in the August 25th<br class="">meeting.<br class=""><br class="">The current situation is that the kata project builds kata pieces<br class="">(which may differ considering whether you're using 2.x or 1.x<br class="">branches) and distributes those together with our own qemu built<br class="">statically and the kernel / initrd / image to be used. And, sincerely,<br class="">this is *a* *lot* to take care of.<br class=""><br class="">My suggestion would be to reduce the amount of work we do, the amount<br class="">of things we build, and start relying more on what the distros can<br class="">provide us. Let me explain.<br class=""><br class="">For instance, we could ...<br class=""><br class="">Stop building & distributing our own VMMs<br class="">=================================<br class="">While I understand the reason why it's done, it'd be better to rely on<br class="">the VMMs shipped by the distros.<br class=""><br class="">In order to do this, we'd have to either approach the distros, or to<br class="">do the tests ourselves, to ensure that their latest release has a VMM<br class="">that's capable of running kata. If the distro has that, we document we<br class="">support the distro. If the distro does not have that, we can provide<br class="">instructions on how to build the VMM, but we take out of our back the<br class="">work of building it statically and shipping to the consumers.<br class=""><br class="">With this, we can do better testing on specific distros and ensure to<br class="">possible consumers of kata where they can run the project and, with<br class="">that, also forward the non kata specific issues to the distros<br class="">themselves.<br class=""></blockquote><div class=""><br class=""></div><div class="">I disagree on this. We are often relying on very recent features in each VMM, and we are opinionated on how we build it (see Kconfig options, configure flags). We want a very specific set of devices and features in each of our VMMs; we don't care about running Windows 95, etc. </div></div></div></div></blockquote></div><br class=""><div class="">This is a valid point, but at least in the case of Fedora, there is</div><div class="">some discussion on building a minimalist qemu for that purpose,</div><div class="">from the same sources as the upstream qemu, and with</div><div class="">the same patches (therefore addressing the same CVEs).</div><div class="">See <a href="https://src.fedoraproject.org/fork/ddd/rpms/qemu/tree/mini" class="">https://src.fedoraproject.org/fork/ddd/rpms/qemu/tree/mini</a>.</div><div class=""><br class=""></div><div class=""><br class=""></div></div></body></html>