Open Stack

> On 12 Aug 2020, at 02:42, Eric Ernst <eric.g.ernst at gmail.com <mailto:eric.g.ernst at gmail.com>> wrote:
> 
> Sorry I missed the call this morning. My takes below.
> 
> --Eric
> 
> On Tue, Aug 11, 2020 at 2:09 PM Fabiano Fidêncio <fidencio at redhat.com <mailto:fidencio at redhat.com>> wrote:
> Folks!
> 
> We have discussed during this week's Architecture's meeting what could
> be a plan for the future with regards to packaging and I'd like to
> drop a suggestion here and then have it discussed in the August 25th
> meeting.
> 
> The current situation is that the kata project builds kata pieces
> (which may differ considering whether you're using 2.x or 1.x
> branches) and distributes those together with our own qemu built
> statically and the kernel / initrd / image to be used. And, sincerely,
> this is *a* *lot* to take care of.
> 
> My suggestion would be to reduce the amount of work we do, the amount
> of things we build, and start relying more on what the distros can
> provide us. Let me explain.
> 
> For instance, we could ...
> 
> Stop building & distributing our own VMMs
> =================================
> While I understand the reason why it's done, it'd be better to rely on
> the VMMs shipped by the distros.
> 
> In order to do this, we'd have to either approach the distros, or to
> do the tests ourselves, to ensure that their latest release has a VMM
> that's capable of running kata. If the distro has that, we document we
> support the distro. If the distro does not have that, we can provide
> instructions on how to build the VMM, but we take out of our back the
> work of building it statically and shipping to the consumers.
> 
> With this, we can do better testing on specific distros and ensure to
> possible consumers of kata where they can run the project and, with
> that, also forward the non kata specific issues to the distros
> themselves.
> 
> 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. 

This is a valid point, but at least in the case of Fedora, there is
some discussion on building a minimalist qemu for that purpose,
from the same sources as the upstream qemu, and with
the same patches (therefore addressing the same CVEs).
See https://src.fedoraproject.org/fork/ddd/rpms/qemu/tree/mini <https://src.fedoraproject.org/fork/ddd/rpms/qemu/tree/mini>.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.katacontainers.io/pipermail/kata-dev/attachments/20200812/a2165cde/attachment-0003.html>