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.
Keep building the kernel
===================
Differently than the suggestion about the VMM, the kernel bits, IMHO,
should still be built. The kernels we build can be used upstream, but
we must ensure those are under no circumstances ready for
production.Why? Because we have no power to track and fix CVEs as the
distros do.
So, we can keep shipping our own kernel and testing using it, but we
should also incentive distros to use (and test) their own kernels with
kata. The reason I say this is because it'd help the project to *not*
require a distro to ship a non-tested kernel, which would drop a
little bit the barrier of accepting kata as their official packages.
Agreed that we should keep building the kernel (again, the config is important, and this can be at least used as a reference).
Stop building & distributing our own distro packages
========================================
While I also understand that building the packages for several distros
may help the users, I don't think this is something that should be on
the kata developer's back.
For this, I'd suggest we take advantage of the kata-operator, being
worked by Harshal and Jens Freimann, and consolidate on that as the
way to install kata in your distro.
I foresee that we have to write some kind of "kata-osinfo" package (as
in, a module, not as in an rpm or deb), where we can store information
about the distro, which are the VMMs supported by the distro, which
are the virt filesystems supported by that distro, etc; By doing this
we can rely on a good documentation, or even on the operator to
install the packages based on the info of each distro, but the only
bit we'll distribute will be the kata binaries themselves.
Doing this, we can keep it simple on our side, while relying more on
the distros.
I want input from users of Kata in production on this. My guess is that most organizations are rolling their own packages or are building their own binaries and deploying via an operator/daemonset like kata-deploy. But, that's my guess. Let's hope that users chime in on this thread.
More specifically: as a user, do you use Kata provided packages? Do you use distro packages? Do you build your own packages/deployment?
I'd also want to get an ACK from the SUSE folks, who worked to add package support in the past.
Thanks for bringing this up Fabiano.
--Eric
Those things would already reduce the maintenance burden and, at the
same time, show to our consumers what's supported and tested from our
side.
Of course, it goes without saying, but here I'm hoping our tests will
follow the same approach and will use the distro packages, ensuring
the basics would be working there and also reporting issues against
the distro packages when needed.
Please, take some time to think about the proposal. I'd love to hear
feedback here in the Mailing List, but if you have something to add,
please, also consider joining the Architecture's meeting on August
25th so we can take our final decision on this topic.
Best Regards,
--
Fabiano Fidêncio
_______________________________________________
kata-dev mailing list
kata-dev@lists.katacontainers.io
http://lists.katacontainers.io/cgi-bin/mailman/listinfo/kata-dev