- kata-dev - lists.katacontainers.io

Kata PR review krew
by Hunt, James O 16 Sep '19

16 Sep '19

Hi All, The Kata PR herder(s) [1] this week are... - Peng Tao (https://github.com/bergwolf) - Archana Shinde (https://github.com/amshinde) The backlog [2] is currently looking pretty good with 30 open PRs (excluding 2 do-not-merge and work-in-progress ones). As always, if you can spare some time to help out with the important task of reviewing these new fixes and features, please reach out to us [3]. Not only is this vital work, it also gives you an easy way to get involved in the Kata community. And who knows where that journey may end [4] ... ? ;) More info at [5] and [6]. Cheers, James [1] - https://github.com/kata-containers/community/wiki/Review-Team-Rota [2] - https://github.com/pulls?utf8=✓&q=is%3Aopen+is%3Apr+org%3Akata-containers+-… <https://github.com/pulls?utf8=%E2%9C%93&q=is%3Aopen+is%3Apr+org%3Akata-cont…> [3] - https://github.com/kata-containers/community/blob/master/README.md#join-us [4] - 千里之行，始于足下 ("A journey of a thousand 'miles' begins with a single step"). [5] - https://github.com/kata-containers/community/wiki/Getting-Started-Contribut… [6] - https://github.com/kata-containers/community/blob/master/CONTRIBUTING.md --- https://katacontainers.io/ | https://github.com/kata-containers <https://github.com/clearcontainers> Open Source Technology Center Intel Corporation (UK) Ltd. - Co. Reg. #1134945 - Pipers Way, Swindon SN3 1RJ.

1 0

Welcome our new and returning architecture committee members
by Ricardo Aravena 16 Sep '19

16 Sep '19

For the September 2019 Kata Containers Architecture Committee elections, we had three seats available and received three candidate nominations. Thus, we shall bypass the question and voting phases of the elections, and move directly to the results announcement. Please welcome back Eric Ernst as a returning member and new members Haomin Tsai and Justin He to the Kata AC. Congratulations all of you! Ricardo

7 6

Architecture Committee candidacy period is now closed
by Ricardo Aravena 13 Sep '19

13 Sep '19

Katacitizens, On behalf of myself, Carlos, and Fupan, I'm happy to announce that the period for Architecture Committee submissions is now closed. We have submissions from: - Eric Ernst - Haomin Tsai - Justin He You can view those submissions at: https://github.com/kata-containers/community/tree/master/elections/arch-com… Given we have three open seats and three candidates, we will jump straight to the announcement of the members on the following email. Thanks! Ricardo

1 0

shares mount options
by Quirin Gylstorff 12 Sep '19

12 Sep '19

Hi, I have a question to the kata mount rules. We are currently looking into possiblities to avoid using privileged docker container in our ci/build system[1]. Currently we are looking into kata-containers. Our build system uses debootstrap to generate a new root file system and needs therefore a file system mounted with the possibility to create new devices. In the current implementation of kata-containers all shares have the nodev option activated, e.g.: none on /data type virtio_fs (rw,nodev,relatime,user_id=0,group_id=0,default_permissions,allow_other,dax) Are there any plans to allow the configuration of the mount rules? From the code the options look hardcoded. Or is there already a way to allow this? Thanks, Quirin [1] https://github.com/ilbers/isar

1 0

Elections for Kata Architecture Committee: Justin He
by Justin He (Arm Technology China) 12 Sep '19

12 Sep '19

Hi All~ Kata-containers Architecture Committee Candidacy Declaration Platform: Arm Candidate: Justin He <Justin.He(a)arm.com> I'm working for Arm Electronic Technology (Shanghai) Co.Ltd. This candidacy is representing Arm company to be voted for one seat of the Kata-container architecture committee. Here is my pr https://github.com/kata-containers/community/pull/121 My current role is Staff Engineering in the Open Source Software Group and I am working on virtualization and container technology on the Arm platform. I have more than 10 years of experience in low level Linux software development, especially for linux kernel [1], DPDK on arm64 [2] and hardware virtualization development including KVM and qemu [3]. [1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/log/?qt=… [2] http://dpdk.org/browse/dpdk/log/?qt=author&q=Jia+He [3] https://git.qemu.org/qemu.git/?p=qemu.git&a=search&h=HEAD&st=author&s=jia+he In recent years, our team started development on RunV project, one of the predecessors to Kata-containers, to enable and enhance the multi-arch support. Our focus areas included KVMtool support, performance profiling of the network and storage devices for virtual machines, and we also worked on stability and density improvements. For example, our team enabled the memory hotplug support, vm template on Kata-containers project. As for virtio-fs support on arm64, we fixed a lot issues on persistent memory and DAX support. For these collaborations, there were public blogs announced at [4] and [5] [4] https://blog.hyper.sh/arm_and_hyper.html [5] https://community.arm.com/iot/b/blog/posts/arm-and-hyper-hq-will-push-runv-…. We have met regularly with Hyper team to discuss the development issues and solutions of the project. For conference presentation, our team members once attended Denver 2019 summit as speakers [4]: https://www.openstack.org/videos/summits/denver-2019/kata-containers-on-arm… Interests: We believe Kata-containers is a fast developing project and that it will have much broader applicability across different architectures and use cases, especially within the emerging next-generation IoT and 5G era! These different use cases will generate new design requirements of the underlying architecture and we believe strongly that good multi-architecture support will be essential to position Kata-containers for broad adoption throughout the cloud native ecosystem. We look forward to driving these changes together, so the Kata-containers project can reach its full potential! -- Cheers, Justin (Jia He) IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

2 1

update on kata in fedora, and some questions
by Cole Robinson 12 Sep '19

12 Sep '19

Hi kata folks. I want to give an update on the state of kata in Fedora, discuss some of the remaining pieces, and ask some questions There's already some pieces of kata in Fedora: kata-ksm-throttler, kata-proxy, kata-shim, kata-osbuilder. They were added around June 2018 by Lokesh Mandvekar. But they are quite out of date at this point, and obviously not that useful because kata-runtime never made it into the distro. The kata-osbuilder package does generate a Fedora initrd and image using the distro specific scripts (not dracut), but I suspect they never worked with the Fedora kernel at least. I spent the past two days getting the osbuilder dracut support to work with the Fedora kernel. I now have the latest OBS kata packages working on Fedora 30 with a stock Fedora kernel, dracut built initrd, and stock Fedora qemu 4.1 build (from the virt-preview repo). Here's the changes I added, see the attached files * configuration.qemu.diff: Changes I made to /etc/kata-containers/configuration.toml compared to /usr/share/defaults/kata-containers/configuration.toml. Besides changing the qemu, kernel, and initrd path as mentioned above, I turned on q35 and vsock too; pc and virtio-serial were working as well, but this is likely the config we will target for Fedora packaging * agent-0001-*.patch: Make kata-agent.service run after systemd-udev-settle.service. At one point in my experimenting I needed this: kata would communicate with the agent, but networking in the guest didn't seem to be set up yet, and configuring eth0 was failing. However if I revert this now it doesn't seem to cause any failures. This may be due to /etc/modules-load.d/kata-modules.conf loading the necessary bits early enough, but that may still be race-y. I figured I'd mention it for posterity. * osbuilder-0001-*: This is a hack. If you use AGENT_SOURCE_BIN=SOMEDIR/kata-agent, rootfs.sh will now use SOMEDIR as the source for installing kata-agent.service and kata-containers.target. We will want something like this in Fedora where we will likely have a standalone kata-agent package shipping a prebuilt kata-agent. We shouldn't have to depend on git and go compilation to build the kata-agent at image generation time. Suggestions welcome on how to implement this in an upstream suitable way * osbuilder-0002-*: This fixes the initrd /sbin/init symlinking for me. The current code leaves /init, /sbin/init, and /usr/lib/systemd/systemd all as symlinks pointing to each other. Maybe this works on another distro but it didn't work on Fedora. Or maybe this is just a bug * 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 After those bits are applied, I build osbuilder with: # cat b.sh IMAGEOUT="$(PWD)/kata-containers-initrd.img" AGENTSRC="/root/go/src/github.com/kata-containers/agent" KVERSION="5.0.9-301.fc30.x86_64" export AGENT_SOURCE_BIN=$AGENTSRC/kata-agent rm -rf dracut_overlay $IMAGEOUT make BUILD_METHOD=dracut DRACUT_KVERSION=$KVERSION initrd Understandably that KVERSION needs to match a kernel installed on the host, and it needs to match the kernel referenced in configuration.toml. IMAGEOUT is the location of the generated initrd, which is also referenced in /etc/kata-containers/configuration.toml. Then I can test with: # podman run -it --runtime=/usr/bin/kata-runtime alpine sh (with selinux disabled on the host though, kata seems to require it for podman usage last I checked). So with that working, the major pieces that need to be finished so that kata can at least be tested with native Fedora packages are: * Update the kata-osbuilder package to use the above info * Update all the existing kata-* packages to latest versions * Package kata-agent and get it accepted into Fedora * Finish the kata-runtime package submission and get it accepted into Fedora After that, the important pieces IMO are: * Get non-x86 support working in Fedora * Find a way to package some kind of docker config snippet so 'docker --runtime=kata-runtime' works out of the box. On Fedora the simplest way I found was to add '--add-runtime kata-runtime=path/to/kata-runtime' in /etc/sysconfig/docker OPTIONS=, but that's not really a programmatic operation * Find a way to get podman to not require selinux=disabled which is a really big hammer. Hopefully it's not hard to make it not error if selinux=permissive which can be changed at runtime. * Get a minimal qemu build into fedora. Christophe and I have some work on this already: https://github.com/c3d/fedora-qemu-mini https://github.com/crobinso/fedora-qemu-mini Now some misc questions that I have after poking around at this: * Is initrd preferred vs image boot? I didn't really try to get image boot working. Should I? * AGENT_INIT=no is the default, meaning /sbin/init == systemd, not /sbin/init == kata-agent. Is that generally the preferred config? When I was flailing around trying to get anything to work I tried AGENT_INIT=yes but didn't get anywhere * At first I spent a lot of time trying to get the old style rootfs scripts to work with the Fedora kernel. But I was hitting some confusing situations. The generated initrd fs would have kata agent and the services in them, but nothing was adding it to basic.target.wants; current code in rootfs.sh this only happens if using the dracut method. So understandably kernel+initrd wouldn't work in that case, because nothing was starting the kata-agent... except when I combined that initrd with the kernel from the kata-linux-container package, the kata container would start up fine! Which really perplexes me... does that kernel have some particular knowledge about starting kata-agent or one of the associated services? Or does it trigger some different systemd behavior somehow? Thanks, Cole

3 3

Haomin comes into elections~~~
by caihaomin 11 Sep '19

11 Sep '19

Hi all~ Haomin Tsai from Huawei Container team wants to join the elections~~ Before I was just a little brother of ZhangWei, Hahaha, now I become a big boy~ I want to make more contribution to Kata and I want to join the AC~~ Here is my pr https://github.com/kata-containers/community/pull/119 Name: Haomin Tsai Email: caihaomin(a)huawei.com Introduction: I am now working as a Senior Engineer in Huawei Corporation, leading a technical team to provide container solutions for other departments in our Corporation and Huawei Public Cloud. We focus on docker/containerd/kata-containers/linux kernel and other infrastructure technology. I am now working on Kunpeng Arch which based on arm64 extended. Before Kata, I was a docker/contaienrd developer and spent time working on operating system. In the early days of Kata's establishment, I participated in it. After that my team and I wishes to make a good product for more users. Last year, our product Huawei Cloud Container Instance(aka CCI) which based on Kata has a rapid growth. After this period of practice, we truely believe that Kata is really a good solution in production. We extended the use of the scene based on Kata and enhanced the scene including genetic calculation, AI calculation, CDN, big data and so on. Talking about community, a good community makes both developers and users comfortable. And I think Kata is one of these communitiesm, beyond this Kata even is going to become the cornerstone of cloud computing, not only in serverless/multi-tenant scene, but also in more general scenes. Next I want to talk a little about future. If I can be honored to take one of the seats, my goals are composed of two parts: First part, I want to promote our production practice which will make users more comfortable. Second part, our team are now working on Kunpeng Arch, and I think we have a further work to do for Kata based on Kunpeng. I hope I can get this seat and make contribution to the community. ^_^ BR~ Haomin

2 1

Elections for Kata Architecture Committee: Eric Ernst
by Ernst, Eric 11 Sep '19

11 Sep '19

Hey ya’ll, Let’s get this election session started! I have enjoyed working on this project, and would love to continue to contribute any way I can. Please find my candidacy PR at [1]. Thanks, Eric [1] - https://github.com/kata-containers/community/pull/117 PS: If anyone needs encouragement to submit their candidacy, please reach out! I’d love to have a diverse group of contributors and users on the committee! -- Name: Eric Ernst Email: eric.ernst(a)intel.com Background: I am a senior software engineer in Intel's Open Source Technology Center, acting both as a contributor as well as a technical lead for the Intel-team contributing to Kata Containers. Before Kata, I spent time working on Clear Containers, and prior to that spent a few years working on Linux kernel. Since the initial discussions of creating Kata started I have been an active contributor and advocate for the project, both in code and in the greater Kata community/ecosystem. While I do work within a silicon company, one of my primary goals for helping guide Kata has been developing a neutral and diverse contribution base. Aside from having a stable, compatible, and viable technical basis for the project, I think a healthy and robust community is key to sustained success. Over the last year, I have served as a member of the Kata Containers architecture committee. The project has matured a lot over the last year, with expanding production usage and user-base. Despite this, we still have a lot of room for development, continuing to improve our density and security profile, all while providing improved manageability and serviceability for users who are deploying Kata. Beyond this work, we will need to focus on attaining and addressing input from end-users, as well as adapting to and influencing the cloud native ecosystem. In other words, we still have a lot of fun work to do! I look forward to continuing to contribute to the project.

3 2

Re: [kata-dev] update on kata in fedora, and some questions
by Marco Vedovati 10 Sep '19

10 Sep '19

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. > 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/roo… 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. BTW, a.t.m. dracut is unit tested with a openSUSE container only, adding Fedora and other would be nice. >>> * 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 > >>> After those bits are applied, I build osbuilder with: >>> >>> # cat b.sh >>> IMAGEOUT="$(PWD)/kata-containers-initrd.img" >>> AGENTSRC="/root/go/src/github.com/kata-containers/agent" >>> KVERSION="5.0.9-301.fc30.x86_64" >>> export AGENT_SOURCE_BIN=$AGENTSRC/kata-agent >>> rm -rf dracut_overlay $IMAGEOUT >>> make BUILD_METHOD=dracut DRACUT_KVERSION=$KVERSION initrd >>> >>> >>> Understandably that KVERSION needs to match a kernel installed on the >>> host, and it needs to match the kernel referenced in configuration.toml. >>> IMAGEOUT is the location of the generated initrd, which is also >>> referenced in /etc/kata-containers/configuration.toml. Then I can > test with: >>> >>> # podman run -it --runtime=/usr/bin/kata-runtime alpine sh >>> >>> (with selinux disabled on the host though, kata seems to require it for >>> podman usage last I checked). >>> >>> >>> So with that working, the major pieces that need to be finished so that >>> kata can at least be tested with native Fedora packages are: >>> >>> * Update the kata-osbuilder package to use the above info >>> * Update all the existing kata-* packages to latest versions >>> * Package kata-agent and get it accepted into Fedora >>> * Finish the kata-runtime package submission and get it accepted into > Fedora >>> >>> After that, the important pieces IMO are: >>> >>> * Get non-x86 support working in Fedora >>> >>> * Find a way to package some kind of docker config snippet so 'docker >>> --runtime=kata-runtime' works out of the box. On Fedora the simplest way >>> I found was to add '--add-runtime kata-runtime=path/to/kata-runtime' in >>> /etc/sysconfig/docker OPTIONS=, but that's not really a programmatic >>> operation >>> >>> * Find a way to get podman to not require selinux=disabled which is a >>> really big hammer. Hopefully it's not hard to make it not error if >>> selinux=permissive which can be changed at runtime. >>> >>> * Get a minimal qemu build into fedora. Christophe and I have some work >>> on this already: https://github.com/c3d/fedora-qemu-mini >>> https://github.com/crobinso/fedora-qemu-mini >>> >>> >>> Now some misc questions that I have after poking around at this: >>> >>> * Is initrd preferred vs image boot? I didn't really try to get image >>> boot working. Should I? >> >> Nope, it's not preferred. But it is packaging friendly. >> > > Yeah thinking about this more it's definitely not memory friendly to use > an initrd. I tried the image building and got the fs generating, but the > Fedora kernel needs some more drivers built in to make it work without > an initrd. I just filed a Fedora kernel bug: > > https://bugzilla.redhat.com/show_bug.cgi?id=1750581 > >>> * AGENT_INIT=no is the default, meaning /sbin/init == systemd, not >>> /sbin/init == kata-agent. Is that generally the preferred config? When I >>> was flailing around trying to get anything to work I tried >>> AGENT_INIT=yes but didn't get anywhere >> >> Agent init may give you a smaller image size and a faster boot time. >> However, you will not be able to load initrd kernel modules when using >> dracut-initrds, so you'll need all the features built into the kernel. >> > > Makes sense > >>> * At first I spent a lot of time trying to get the old style rootfs >>> scripts to work with the Fedora kernel. But I was hitting some confusing >>> situations. The generated initrd fs would have kata agent and the >>> services in them, but nothing was adding it to basic.target.wants; >>> current code in rootfs.sh this only happens if using the dracut method. >>> So understandably kernel+initrd wouldn't work in that case, because >>> nothing was starting the kata-agent... except when I combined that >>> initrd with the kernel from the kata-linux-container package, the kata >>> container would start up fine! Which really perplexes me... does that >>> kernel have some particular knowledge about starting kata-agent or one >>> of the associated services? Or does it trigger some different systemd >>> behavior somehow? >> >> >> - When the sandbox is started using a regular image, the kernel cmdline >> includes "systemd.unit=kata-containers.target" >> See here: >> > https://github.com/kata-containers/runtime/blob/master/pkg/katautils/create… >> >> - When using initrd instead, it is supposed that the init == agent. >> However for the dracut generated initrd, the kata-containers.target is >> added to basic.target.wants. >> See here: >> > https://github.com/kata-containers/osbuilder/blob/master/rootfs-builder/roo… >> > > Great, thanks for the pointers > > Thanks, > Cole >

2 2

Cancel the meeting this week
by Xu Wang 10 Sep '19

10 Sep '19

Hi folks, There is no items in the agenda, and the antfin (hyper.sh) guys are attending the anniversary party this moment. Let's cancel the meeting this week and discuss in mailing list and slack channels. Cheers! Xu

2 1

Agenda items for AC call this week
by Ernst, Eric 10 Sep '19

10 Sep '19

Last call for agenda items for call tomorrow, otherwise I propose canceling. Cheers, Eric

1 0

Re: [kata-dev] update on kata in fedora, and some questions
by Cole Robinson 10 Sep '19

10 Sep '19

On 9/9/19 12:09 PM, Marco Vedovati wrote: > Hi Cole, > it's nice to see more distros trying to have Kata pkgs! > > I can leave you some feedbacks inline, based on the work I did to > package Kata for openSUSE [1], and since I worked on adding support for > dracut in osbuilder (based on the initial work of Stefan Hajnoczi). > > Cheers > Marco > > [1]: > https://build.opensuse.org/package/show/openSUSE:Factory/katacontainers > https://build.opensuse.org/package/show/openSUSE:Factory/katacontainers-ima… > Thank you for the dracut work! It will simplify things on the Fedora side quite a bit :) > > On 9/8/19 3:10 AM, Cole Robinson wrote: >> Hi kata folks. I want to give an update on the state of kata in Fedora, >> discuss some of the remaining pieces, and ask some questions >> >> There's already some pieces of kata in Fedora: kata-ksm-throttler, >> kata-proxy, kata-shim, kata-osbuilder. They were added around June 2018 >> by Lokesh Mandvekar. But they are quite out of date at this point, and >> obviously not that useful because kata-runtime never made it into the >> distro. The kata-osbuilder package does generate a Fedora initrd and >> image using the distro specific scripts (not dracut), but I suspect they >> never worked with the Fedora kernel at least. >> >> I spent the past two days getting the osbuilder dracut support to work >> with the Fedora kernel. I now have the latest OBS kata packages working >> on Fedora 30 with a stock Fedora kernel, dracut built initrd, and stock >> Fedora qemu 4.1 build (from the virt-preview repo). Here's the changes I >> added, see the attached files >> >> * configuration.qemu.diff: Changes I made to >> /etc/kata-containers/configuration.toml compared to >> /usr/share/defaults/kata-containers/configuration.toml. Besides changing >> the qemu, kernel, and initrd path as mentioned above, I turned on q35 >> and vsock too; pc and virtio-serial were working as well, but this is >> likely the config we will target for Fedora packaging > > Probably you can keep this changes downstream, and have it done by the > spec file. > Make sense >> * agent-0001-*.patch: Make kata-agent.service run after >> systemd-udev-settle.service. At one point in my experimenting I needed >> this: kata would communicate with the agent, but networking in the guest >> didn't seem to be set up yet, and configuring eth0 was failing. However >> if I revert this now it doesn't seem to cause any failures. This may be >> due to /etc/modules-load.d/kata-modules.conf loading the necessary bits >> early enough, but that may still be race-y. I figured I'd mention it for >> posterity. > > I recon there may be a race between the two services, logically > kata-agent should be started after the kernel modules are loaded. I have > opened a new issue here (contributions are welcome :D ): > https://github.com/kata-containers/osbuilder/issues/353 > Thanks, I added a comment there > >> * osbuilder-0001-*: This is a hack. If you use >> AGENT_SOURCE_BIN=SOMEDIR/kata-agent, rootfs.sh will now use SOMEDIR as >> the source for installing kata-agent.service and kata-containers.target. >> We will want something like this in Fedora where we will likely have a >> standalone kata-agent package shipping a prebuilt kata-agent. We >> shouldn't have to depend on git and go compilation to build the >> kata-agent at image generation time. Suggestions welcome on how to >> implement this in an upstream suitable way > > Why you don't want to build the kata-agent at image generation time? > kata-agent does not need to be a standalone package, since it should not > be installed on the host. > 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. >> * osbuilder-0002-*: This fixes the initrd /sbin/init symlinking for me. >> The current code leaves /init, /sbin/init, and /usr/lib/systemd/systemd >> all as symlinks pointing to each other. Maybe this works on another >> distro but it didn't work on Fedora. Or maybe this is just a bug > > This is not what is happening for me: > init -> usr/lib/systemd/systemd > /sbin/init -> ../usr/lib/systemd/systemd > /usr/lib/systemd/systemd > With current git, the overlay has /init -> ./usr/lib/systemd/systemd /lib/systemd/systemd -> ../../init /sbin/init -> ../init But when this is serialized into the initrd, on Fedora at least, /lib is a symlink to /usr/lib. So in practice the second symlink overwrites the systemd binary at /usr/lib/systemd/system. 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 >> * 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. > >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 >> After those bits are applied, I build osbuilder with: >> >> # cat b.sh >> IMAGEOUT="$(PWD)/kata-containers-initrd.img" >> AGENTSRC="/root/go/src/github.com/kata-containers/agent" >> KVERSION="5.0.9-301.fc30.x86_64" >> export AGENT_SOURCE_BIN=$AGENTSRC/kata-agent >> rm -rf dracut_overlay $IMAGEOUT >> make BUILD_METHOD=dracut DRACUT_KVERSION=$KVERSION initrd >> >> >> Understandably that KVERSION needs to match a kernel installed on the >> host, and it needs to match the kernel referenced in configuration.toml. >> IMAGEOUT is the location of the generated initrd, which is also >> referenced in /etc/kata-containers/configuration.toml. Then I can test with: >> >> # podman run -it --runtime=/usr/bin/kata-runtime alpine sh >> >> (with selinux disabled on the host though, kata seems to require it for >> podman usage last I checked). >> >> >> So with that working, the major pieces that need to be finished so that >> kata can at least be tested with native Fedora packages are: >> >> * Update the kata-osbuilder package to use the above info >> * Update all the existing kata-* packages to latest versions >> * Package kata-agent and get it accepted into Fedora >> * Finish the kata-runtime package submission and get it accepted into Fedora >> >> After that, the important pieces IMO are: >> >> * Get non-x86 support working in Fedora >> >> * Find a way to package some kind of docker config snippet so 'docker >> --runtime=kata-runtime' works out of the box. On Fedora the simplest way >> I found was to add '--add-runtime kata-runtime=path/to/kata-runtime' in >> /etc/sysconfig/docker OPTIONS=, but that's not really a programmatic >> operation >> >> * Find a way to get podman to not require selinux=disabled which is a >> really big hammer. Hopefully it's not hard to make it not error if >> selinux=permissive which can be changed at runtime. >> >> * Get a minimal qemu build into fedora. Christophe and I have some work >> on this already: https://github.com/c3d/fedora-qemu-mini >> https://github.com/crobinso/fedora-qemu-mini >> >> >> Now some misc questions that I have after poking around at this: >> >> * Is initrd preferred vs image boot? I didn't really try to get image >> boot working. Should I? > > Nope, it's not preferred. But it is packaging friendly. > Yeah thinking about this more it's definitely not memory friendly to use an initrd. I tried the image building and got the fs generating, but the Fedora kernel needs some more drivers built in to make it work without an initrd. I just filed a Fedora kernel bug: https://bugzilla.redhat.com/show_bug.cgi?id=1750581 >> * AGENT_INIT=no is the default, meaning /sbin/init == systemd, not >> /sbin/init == kata-agent. Is that generally the preferred config? When I >> was flailing around trying to get anything to work I tried >> AGENT_INIT=yes but didn't get anywhere > > Agent init may give you a smaller image size and a faster boot time. > However, you will not be able to load initrd kernel modules when using > dracut-initrds, so you'll need all the features built into the kernel. > Makes sense >> * At first I spent a lot of time trying to get the old style rootfs >> scripts to work with the Fedora kernel. But I was hitting some confusing >> situations. The generated initrd fs would have kata agent and the >> services in them, but nothing was adding it to basic.target.wants; >> current code in rootfs.sh this only happens if using the dracut method. >> So understandably kernel+initrd wouldn't work in that case, because >> nothing was starting the kata-agent... except when I combined that >> initrd with the kernel from the kata-linux-container package, the kata >> container would start up fine! Which really perplexes me... does that >> kernel have some particular knowledge about starting kata-agent or one >> of the associated services? Or does it trigger some different systemd >> behavior somehow? > > > - When the sandbox is started using a regular image, the kernel cmdline > includes "systemd.unit=kata-containers.target" > See here: > https://github.com/kata-containers/runtime/blob/master/pkg/katautils/create… > > - When using initrd instead, it is supposed that the init == agent. > However for the dracut generated initrd, the kata-containers.target is > added to basic.target.wants. > See here: > https://github.com/kata-containers/osbuilder/blob/master/rootfs-builder/roo… > Great, thanks for the pointers Thanks, Cole

1 0

a couple of questions about Kata
by 하영 10 Sep '19

10 Sep '19

2 1

September 2019 Kata Containers Architecture Committee elections are open!
by Ricardo Aravena 09 Sep '19

09 Sep '19

Hello Kata Citizens, On behalf of myself, Ricardo Aravena (rico), Salvador Fuentes (from Intel), and Fupan Li as the approved election officials, it's a pleasure to announce that the Kata Containers architecture committee elections for September 2019 are open! The timeline for the election process is: * Election officials approved by AC: September 3 * Candidacy open: September 3 - 12 * "Debate period": September 12 - 20 * Voting: September 20 - September 27 * Results: September 30 The window is now open for candidates to post their submissions. The process to submit a nomination is: 1) Review the responsibilities of the Architecture Committee members [1] 2) Between now and Sep 12 at 14:59 UTC, you can declare your candidacy for one of the open seats by submitting a textfile with your name (please put your name as the file name), the reason for running and your platform/objectives to this folder[2]. Please also send a message to the kata-dev ML with this same info, declaring your candidacy. Who can vote: Anyone who has had a commit merged into the project in the last 12 months will be eligible to vote. All eligible voters will receive an email with a link to the voting system once the voting period opens. More details of the election process are outlined at [3] and in the etherpad at [4]. Note, once candidacy entry has closed and we enter the debate period. We will be openly asking the candidates some questions around their candidacy. The community is encouraged to submit questions via the election officials and etherpad at [4] - get your thinking caps on now in preparation... we shall then filter, review, and choose a set of suitable questions for the candidates. Please let us know if you have any questions about running for a seat or the election process! [1] https://github.com/kata-containers/community/tree/master/elections #architecture-committee-responsibilities [2] https://github.com/kata-containers/community/tree/master/elections/arch-com… [3] https://github.com/kata-containers/community/tree/master/elections [4] https://etherpad.openstack.org/p/KataArchCommElections_Sep2019

1 1

This weeks Kata Rota
by Hunt, James O 09 Sep '19

09 Sep '19

Hi All, The Kata Kat herder(s) [1] this week are... - Gaby (https://github.com/GabyCT) ! Graham is on hols so to avoid Gaby feeling lonely, it would be great if we could get some impromptu volunteers to help her tackle the backlog [2] ! Although we managed to close 34 PRs last week, due to the rapid pace of development, we still have 41 open PRs so if you can spare some time to help, that would be much appreciated. Remember, the quicker we land PRs, the quicker everyone benefits from fixes and new features. As usual, all are welcome to contribute - take a look at [3][4][5] and become a Kool Kat! Cheers, James [1] - https://github.com/kata-containers/community/wiki/Review-Team-Rota [2] - https://github.com/pulls?utf8=✓&q=is%3Aopen+is%3Apr+org%3Akata-containers+-… <https://github.com/pulls?utf8=%E2%9C%93&q=is%3Aopen+is%3Apr+org%3Akata-cont…> [3] - https://github.com/kata-containers/community/blob/master/README.md#join-us [4] - https://github.com/kata-containers/community/wiki/Getting-Started-Contribut… [5] - https://github.com/kata-containers/community/blob/master/CONTRIBUTING.md --- https://katacontainers.io/ | https://github.com/kata-containers <https://github.com/clearcontainers> Open Source Technology Center Intel Corporation (UK) Ltd. - Co. Reg. #1134945 - Pipers Way, Swindon SN3 1RJ.

1 0

Want to join Kata Slack
by 하 영 05 Sep '19

05 Sep '19

Hello, I’m recently interested in Kata, and I want to join slack.(bit.ly:KataSlack) May I have your invitation? Sincerely, Young

4 3

Open Infrastructure Summit Shanghai: Forum Submissions Open
by Jimmy McArthur 05 Sep '19

05 Sep '19

Hello Everyone! We are now accepting Forum [1] submissions for the 2019 Open Infrastructure Summit in Shanghai [2]. Please submit your ideas through the Summit CFP tool [3] through September20th. Don't forget to put your brainstorming etherpad up on the Shanghai Forum page [4]. This is not a classic conference track with speakers and presentations. OSF community members (participants in development teams, operators, working groups, SIGs, and other interested individuals) discuss the topics they want to cover and get alignment on and we welcome your participation. The Forum is your opportunity to help shape the development of future project releases. More information about the Forum [1]. Keep in mind, Forum submissions are for discussions, not presentations. The timeline for submissions is as follows: Sep 4th | Formal topic submission tool opens: https://cfp.openstack.org. Sep 20th | Deadline for proposing Forum topics. Scheduling committee meeting to make draft agenda. Sep 30th | Draft Forum schedule published. Crowd sourced session conflict detection. Forum promotion begins. Oct 7th | Scheduling committee final meeting Oct 14th | Forum schedule final Nov 4-6| Forum Time! If you have questions or concerns, please reach out to speakersupport(a)openstack.org <mailto:speakersupport@openstack.org>. Cheers, Jimmy [1] https://wiki.openstack.org/wiki/Forum [2] https://www.openstack.org/summit/shanghai-2019/ [3] https://cfp.openstack.org [4] https://wiki.openstack.org/wiki/Forum/Shanghai2019

1 0

Herd of rotating gate review Kats (or something)
by Hunt, James O 02 Sep '19

02 Sep '19

Hi All, The Kata herders [1] for the week are: - Julio (https://github.com/devimc) - Ricardo (https://github.com/raravena80) - et moi (https://github.com/jodh-intel) We currently have 40 open PRs in the queue [2] (or 63 including "do-not-merge" and "wip" PRs). As always, if you'd like to help, please contact us [3], or just dive straight in [4][5]. Cheers, James [1] - https://github.com/kata-containers/community/wiki/Review-Team-Rota [2] - https://github.com/pulls?utf8=✓&q=is%3Aopen+is%3Apr+org%3Akata-containers+-… <https://github.com/pulls?utf8=%E2%9C%93&q=is%3Aopen+is%3Apr+org%3Akata-cont…> [3] - https://github.com/kata-containers/community/blob/master/README.md#join-us [4] - https://github.com/kata-containers/community/wiki/Getting-Started-Contribut… [5] - https://github.com/kata-containers/community/blob/master/CONTRIBUTING.md --- https://katacontainers.io/ | https://github.com/kata-containers <https://github.com/clearcontainers> Open Source Technology Center Intel Corporation (UK) Ltd. - Co. Reg. #1134945 - Pipers Way, Swindon SN3 1RJ.

1 0

Cancel AC call today
by Ernst, Eric 27 Aug '19

27 Aug '19

Hey ya’ll, Several of us are traveling today and we don’t have anything on agenda for AC call – let’s cancel! --Eric

2 1

Gateherding...
by Whaley, Graham 27 Aug '19

27 Aug '19

Good morning, (apologies for the late email - public holiday here yesterday). This week's herders are: - Frank - Carlos https://github.com/kata-containers/community/wiki/Review-Team-Rota We have 38 open issues, 62 if you include WIP and DNM (hmm, one day I wonder if they will reach 1:1 parity?? ;-) ). Interesting historical note then - and there have been 3385 Issues *closed* in the past :-) Graham --------------------------------------------------------------------- Intel Corporation (UK) Limited Registered No. 1134945 (England) Registered Office: Pipers Way, Swindon SN3 1RJ VAT No: 860 2173 47 This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies.

1 0

PTG Attendance
by Kendall Nelson 24 Aug '19

24 Aug '19

Hello Everyone! This is the list of groups that are plannning on attending the PTG. Thank you PTLs/Chairs/Leads that responded on time :) I hesitate to say it's the 'final' list since I had a few groups respond with a 'Maybe', but it's probably pretty close. Please also note that the tentative activities at the PTG vary by group. Some groups are planning on only doing onboarding for example. Without further ado, here is the list! Airship Auto-Scaling SIG Barbican Blazar CInder Cyborg Edge Computing Group Fenix First Contact SIG Gitea Glance Heat Horizon I18n Ironic K8s SIG Karbor Kata Containers Keystone Loci Manila Meta SIG Monasca Neutron Nova Octavia OpenStack Charms OpenStack Infra / OpenDev OpenStack TC Openstack-helm OpenStack Operators (Ops Docs SIG and Meetup group) Oslo Public Cloud SIG Quality Assurance Release Management Scientific SIG Self-healing SIG Storlets StoryBoard Swift Tacker StarlingX If your team is missing from the list, please let me know ASAP as we are starting to put together a draft schedule. -Kendall Nelson(diablo_rojo)

1 0

Shanghai Forum Selection Committee
by Jimmy McArthur 22 Aug '19

22 Aug '19

Hello Kata Containers! The Forum in Shanghai is rapidly approaching. We would love 1 volunteer from Kata for the Forum Selection Committee. Ideally, the volunteer would already be serving in some capacity in a governance role for your project. For information on the Summit in Shanghai: https://www.openstack.org/summit/shanghai-2019/ For more information on the Forum, please see:https://wiki.openstack.org/wiki/Forum Please reach out to myself orknelson(a)openstack.org if you're interested. Volunteers should respond on or before September 2, 2019. Cheers, Jimmy

1 0

Kata NEMU support - plan for deprecation
by Ernst, Eric 21 Aug '19

21 Aug '19

During the August 13th Architecture Committee member, we decided that it makes sense to announce and plan for deprecation of the NEMU VMM for the Kata Containers project. I was very excited about the improvements in the NEMU project, as it aligned very well with Kata’s desire to provide lightweight and fast virtual machines. Fortunately, many of the end-user benefits of NEMU are making their way or are already available in QEMU 4.1, and the team behind NEMU is focusing on advancements around rust-vmm. We will still include NEMU as part of our static release in 1.9, but we do not recommend using NEMU in production. Our initial offering of virtio-fs was based on patches on top of the NEMU hypervisor. Going forward, while we wait for virtio-fs to hit upstream (crossing fingers for QEMU 4.2), we will create QEMU artifacts and a Kata configuration which tracks the virtio-fs QEMU branch. If you have any concerns based on the information above, please don’t hesitate to reach out. Thanks, Eric

1 0

[ANNOUNCE] virtio-fs v0.3 release
by Stefan Hajnoczi 20 Aug '19

20 Aug '19

I am delighted to announce the release of virtio-fs v0.3, a shared file system that lets virtual machines access a directory tree on the host. This release is based on QEMU 4.1.0 and Linux 5.3-rc3. For more information about virtio-fs: https://virtio-fs.gitlab.io/ This is a development release aimed at early adopters of virtio-fs. Work is being done to upstream the code into Linux and QEMU. We expect to stop publishing virtio-fs releases once the code has been merged by these upstream projects. Where to get it: https://gitlab.com/virtio-fs/linux/-/tags/virtio-fs-v0.3 https://gitlab.com/virtio-fs/qemu/-/tags/virtio-fs-v0.3 Changes: * Please note that the mount syntax has changed to: # mount -t virtio_fs myfs /mnt -o ... The old syntax was "mount -t virtio_fs none /mnt -o tag=myfs,...". * virtiofsd --fd=FDNUM takes a listen socket file descriptor number. File descriptor passing is an alternative way to manage the vhost-user UNIX domain socket. The parent process no longer needs to wait for virtiofsd to create the listen socket before spawning the VM. * virtiofsd --syslog logs to syslog(2) instead of stderr. Useful for unifying logging and when the virtiofsd process is not being supervised. * virtiofsd --thread-pool-size=NUM sets the maximum number of worker threads for FUSE request processing. This can be used to control the host queue depth. The default is 64. * Performance improvements and bug fixes. Note for Kata Containers: the new kernel is not compatible with existing Kata Containers releases due to the mount syntax change. To try it out, please apply the following kata-runtime patch: https://gitlab.com/virtio-fs/runtime/commit/a2e44de817e438c02a495cf25803977… Kata Containers patches for virtio-fs v0.3 are under development and will be submitted to Kata soon. Thanks to the following people for contributing code and to many more for helping the virtio-fs effort: Dr. David Alan Gilbert <dgilbert(a)redhat.com> Eric Ren <renzhen(a)linux.alibaba.com> Eryu Guan <eguan(a)linux.alibaba.com> Ganesh Maharaj Mahalingam <ganesh.mahalingam(a)intel.com> Jiufei Xue <jiufei.xue(a)linux.alibaba.com> Liu Bo <bo.liu(a)linux.alibaba.com> Masayoshi Mizuma <m.mizuma(a)jp.fujitsu.com> Miklos Szeredi <mszeredi(a)redhat.com> Peng Tao <tao.peng(a)linux.alibaba.com> piaojun <piaojun(a)huawei.com> Sebastien Boeuf <sebastien.boeuf(a)intel.com> Stefan Hajnoczi <stefanha(a)redhat.com> Vivek Goyal <vgoyal(a)redhat.com> Xiaoguang Wang <xiaoguang.wang(a)linux.alibaba.com>

6 6

Herding this week
by Whaley, Graham 19 Aug '19

19 Aug '19

Good morning, This week's herders for Kata are: - Eric - Salvador - Ganesh https://github.com/kata-containers/community/wiki/Review-Team-Rota We have 39 open issues for review. 63 if we count WIP and DNM... I think that's still quite a healthy number, in a good way, but, does not mean we cannot chip away at it more ;-) Graham --------------------------------------------------------------------- Intel Corporation (UK) Limited Registered No. 1134945 (England) Registered Office: Pipers Way, Swindon SN3 1RJ VAT No: 860 2173 47 This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies.

1 0