Open Stack

On 2020/8/12 05:09, Fabiano Fidêncio 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.
> 
> 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.
> 
> 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.
> 
Thanks for bringing it up and sorry for chiming in late. IMO the purpose 
of building/shipping packages is to make sure users get to install and 
use Kata Containers as easy as possible. We started building and 
distributing distro packages for the exact purpose.

> 
> 
> 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.
Yes, we have been doing a lot of distribution work and it becomes a 
burden. If there are other ways to do it, it would be very good for us 
to shift the burden. Could we do a round of query, and see which 
distributions agrees to ship Kata Containers packages? And we can play 
an upstream role for those distributions.

Take Fedora for example, if someone can stand up and become a package 
maintainer for Kata Containers (starting from rawhide of course), it 
would be pretty reasonable for Kata Community to stop building/shipping 
Kata Containers Fedora in OBS.

My concern is that we might not be able to find enough package 
maintainers for each distribution. Then a possible solution is that we 
rely on package maintainers for those distributions that we can find a 
package maintainer, and continue building distribution packages for 
those we cannot.

Cheers,
Tao

-- 
Into something rich and strange.