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> 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.