[kata-dev] Supported OSes, packaging plans for the future & some ideas

Fabiano FidĂȘncio fidencio at redhat.com
Wed Aug 12 06:54:59 UTC 2020


Eric,

On Wed, Aug 12, 2020 at 2:42 AM Eric Ernst <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> 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.

I understand your point. But do we really have to build the VMMs
ourselves, distribute those ourselves, patch those ourselves, receive
bug reports of those ourselves?
IMHO, we should keep documenting what's the optimal way, what's the
recommended way. However, we should not take the bullet to distribute
those as we currently do. Do you want a very very minimal QEMU that
fits your needs? Cool, build it following our documentation. You don't
think you need that? Better, just use whatever your distro provides
and be happy.

[...]

Best Regards,
-- 
Fabiano FidĂȘncio




More information about the kata-dev mailing list