On 12 Aug 2020, at 02:42, Eric Ernst <eric.g.ernst@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@redhat.com <mailto:fidencio@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.