Open Stack

On 9/10/19 6:11 AM, Marco Vedovati wrote:
> Hi Cole,
> see inline for more clarifications.
> 
> Thanks
> Marco
> 
> (PS: I'm using another address, @suse.com doesn't deliver to
> kata-dev anymore)
> 
> 
> On Tuesday, September 10, 2019 1:45 AM, Cole Robinson wrote:
>> Requiring content from a non-distro network source during a package
>> build process is definitely a distro no no, at least for Fedora.
>> Generally builds aren't expected to require network access for one thing
>>
>> Right now in the existing fedora kata-osbuilder package, the initrd and
>> image are actually built at package install time, so that we can use the
>> host installed kernel and modules, and not have to ship a separate
>> kernel (which is also against Fedora policies). If we pull kata-agent
>> from git at package install time, this means the package has a runtime
>> dep on git and golang, which is not very friendly.
>>
>> So while indeed kata-agent doesn't really have any usage on the host,
>> the most distro friendly way I can think to handle this is to make
>> kata-agent its own package, install the binary and systemd files in
>> /usr/libexec or somewhere else out of the way, and have the initrd build
>> process access those on the host FS.
> 
> 
> This is what I am doing for openSUSE (package link in my first email):
> 
> - The image package sources include tarballs of both the agent and of
> the osbuilder
> source code.
> 
> - The spec file contains a `BuildRequires: go` line.
> 
> - The %build step runs the `make initrd` build target, to build the
> agent and
> to generate an initrd using dracut.
> 
> - The %install steps copies the initrd inside the final rpm.
> 
> - There's not need to run any complex %post step on the host.
> 

Thanks for the info. I didn't see the package link in your first mail,
that's very useful.

Your method is definitely simpler, but I do not think it is acceptable
per Fedora's guidelines, because the package is shipping a copy of the
kernel. Yes it's just a copy of the distribution packaged kernel but
from Fedora perspective that doesn't matter. It also has the downside
that any time the distro kernel is updated, like for security issues,
you will want to ensure the kata-osbuilder package is rebuilt as well so
it's not bundling a potentially vulnerable kernel

Also I'm curious, what is kernel-kvmsmall? Does it not have modules and
everything is built in? Fedora doesn't have anything like that, there's
just one build.

> 
>> For Fedora it seems like /init doesn't matter for the boot process at
>> all and nothing seems to set it by default. Are those strictly required
>> for SUSE? There's probably some set of commands that will work for both
> 
> When using the dracut build method, these sets of links are created here:
> 
> https://github.com/kata-containers/osbuilder/blob/master/rootfs-builder/rootfs.sh#L387
> 
> If I recall correctly, I just tried to replicate the set of links
> created using the non-dracut build method.
> 
> Feel free to open a PR to improve this and add support for Fedora.

Okay, will do.

> BTW, a.t.m. dracut is unit tested with a openSUSE container only, adding
> Fedora and other would be nice.
> 

Sure I'll take a look at the tests

> 
>>>> * osbuilder-0003-*: This extends the dracut config with the list of
>>>> kernel driver module names we need in the initrd. Not all virtio devices
>>>> are listed here because in Fedora some of them are already compiled in
>>>> (virtio_pci, virtio_rng at least). The list is: 9p 9pnet_virtio
>>>> vmw_vsock_virtio_transport virtio_console virtio_blk virtio_scsi
>>>> virtio_net. I presume this will stay downstream only
>>>
>>> Nice, I think it makes sense to have a predefined list of virtualization
>>> specific kernel modules to add. You can create a PR for that.
>>> I am wondering however what could happen if some of these modules are
>>> already built-in in the kernel file.
>>>
> 
> Cool!
> 
> 
>>
>> >From dracut perspective it doesn't seem to have any direct impact. I
>> just tested adding virtio_pci which is built in on Fedora, no
>> complaints. Adding an invalid module name though will make
>> systemd-module-load service report failure, but that's just noise

I will send a PR too extending the drivers= list, maybe we can get away
with having a shared list and we don't need to differentiate based on
host distro.

Thanks,
Cole