- kata-dev - lists.katacontainers.io

Kata Booth at KubeCon Seattle
by Claire Massey 29 Nov '18

29 Nov '18

Hi everyone, KubeCon Seattle is less than two weeks away! We’re excited to have a dedicated Kata Containers booth at the event to provide more visibility for the project and a central location for community outreach, education and collaborative discussions. If you’re planning to attend the event, please review the KubeCon schedule[1] and add your name to the etherpad[2]. We’d also love it if you would sign-up to volunteer some hours in the Kata booth! Myself and other members of the OSF staff will also be there to support the booth, but as Kata experts, you are the real people who attendees are going to want to talk to. I’ve created a temporary slack channel, #kubeconseattle2018, to use is for onsite coordination during the event. Feel free to join the open channel. At the booth we will have the Kata one pager collateral, the new Kata install postcard and plenty of stickers and socks to distribute. The booth number is S17 on the expo hall floor. Let me know if you have any questions. Thanks, Claire [1] https://events.linuxfoundation.org/events/kubecon-cloudnativecon-north-amer… <https://events.linuxfoundation.org/events/kubecon-cloudnativecon-north-amer…> [2] https://etherpad.openstack.org/p/KataKubeConBooth <https://etherpad.openstack.org/p/KataKubeConBooth>

1 0

Gatekeepers this week
by Whaley, Graham 26 Nov '18

26 Nov '18

Good morning! Gatekeepers this week are..... me! https://github.com/kata-containers/community/wiki/Review-Team-Rota#the-rota I'm aware others are active in review as well right now, and many thanks to those contributors. Let's fire a couple of stats out then... We have 56 Issues open right now (a touch high for the project - we seem to hover around 40 quite often), BUT, 21 of those issues are currently marked as DO-NOT-MERGE. And for kicks, I updated the Cauldron.io stats page for the kata project: http://cauldron.io/dashboards/kata-containers 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

[ANNOUNCEMENT] Kata Containers 1.4.0 release
by Tao Peng 23 Nov '18

23 Nov '18

Hello Kata-ers, I am happy to announce Kata Containers 1.4.0 release. It comes with several nice new features and many bug-fixes. All users are recommended to upgrade. The 1.4.0 release highlights following features: - Host cgroups support: qemu process and vcpu threads are now put in proper cpu cgroup in the host and cpu quota and period are used to constrain them. - NEMU `virt` machine type support: The new machine type is specially optimized for cloud environments and thus a great fit for Kata Containers use case. For more information about NEMU, see https://github.com/intel/nemu. - New NetInterworkingModel `none`: It works with tap endpoint types so that enlightened CNI plugins can add tap devices to a sandbox directly, bypassing host network namespaces and thus provide better performance with less network setup complexity. - New NetInterworkingModel `tcfilter`: Yet another method for Kata Containers to bridge the host netns veth and guest tap device, with TC filter rules. With it, Kata Containers have better compatibility with different network endpoint types. - Enable macvlan and ipvlan network support: These two networking models provide lightweight and fast access to underlay or host interfaces without NATTing. - Guest rootfs image can now have a `guest_hook_path` to save a bunch of prestart/poststart/prestop/poststop hook binaries, and they will be executed in the guest at specified container life cycle point accordingly. For full details, please see https://github.com/kata-containers/runtime/releases/tag/1.4.0 Kudos to all Kata community members for making it happen! Cheers, Tao -- bergwolf(a)hyper.sh

4 3

[ac] Identifying VMT members and moderation of embargo-notice ML
by Jeremy Stanley 22 Nov '18

22 Nov '18

Now that community PR#39 has merged and https://github.com/kata-containers/community/blob/master/VMT/VMT.md officially exists, it would be good to have the Kata Containers Architecture Committee properly delegate the functions described there to an initial small team of trusted volunteers from the Kata Containers community. This delegation should then be followed by some durable reference publication (perhaps within the above document) of a list of their names, contact addresses and OpenPGP public key fingerprints both to act as a fallback reporting channel in cases where Launchpad bug filing is undesired by the reporter and also to make it possible for the public at large to verify signed notices originating from these individuals. A corresponding item has been added to the 2018-11-05 AC call agenda. The reason I'm raising this is, in part, because the embargo-notice ML Anne set up (which is intended for advance distribution of vulnerability fixes to downstream stakeholders of Kata software) is still only moderated by OSF staff at the moment. Ideally, the task of moderating this list would be handed off to the Kata Containers Vulnerability Management Team so that it serves as a final cross-check of each others' embargoed pre-KCSA notices to downstream stakeholders. If the AC wishes I'm willing to also participate as a list admin/moderator of last resort, in case there are emergency technical issues with management of the ML itself (as a longstanding member of the OpenStack project VMT I help run the corresponding mailing list it uses, so am well-versed in these matters). It would also be good to ensure that the LP project https://launchpad.net/katacontainers.io (used both for private reporting of suspected security vulnerabilities and also formal requests to become subscribers of the embargo-notice ML) is shared with the Kata Containers VMT so that they can perform the functions outlined in their published process. I'm happy to assist the AC with making those configuration changes if desired. -- Jeremy Stanley

1 1

Herders, and releasers...
by Whaley, Graham 19 Nov '18

19 Nov '18

Good morning! This week's KatHerders are Ricardo and James. https://github.com/kata-containers/community/wiki/Review-Team-Rota#the-rota Note - we also have a new 'Release team' rota page, and this week is a release week (v1.4), driven by Peng (@bergwolf) https://github.com/kata-containers/community/wiki/Release-Team-Rota#the-rota and finally, it is Thanksgiving in the U.S. this Thursday, so some folks may be OOO for all/part of the week. 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

[release-team] 1.4, and introduction of release rota
by Ernst, Eric 19 Nov '18

19 Nov '18

Hey folks, As has been discussed already, we are due for a 1.4 release. There are some good features which we look forward to in this release, including: Macvlan support, tc-mirroring support, hopefully seccomp support, nemu support, open-tracing, etc. While a couple of these items (agent’s tracing support, seccomp support) are still in flight, I’m hopeful they will be completed by the time we have 1.4 ready, otherwise we can push these to 1.5. Next week is Thanksgiving in the united states, but I am hopeful that we can get the release part of it done before EOW, leveraging our colleagues in China? We can delay social media push for the release to early the following week (ie, blog post). Bergwolf/Xu – can you help here for this release for Wednesday of next week? Going forward, I have started a wiki page that is very similar to [1], providing a documented rotation and schedule for releases, available at [2]. This is pretty bare bones at the moment, and I’m happy to have others contribute to the page itself. I am planning on marking it as a 2 week cadence at this point, with release on Wednesdays. I would like to at least have owners on here from Intel, Huawei and Hyper.sh, based on prior discussions, but would like to have others available to support as well. Feedback? Thanks Eric [1] – https://github.com/kata-containers/community/wiki/Review-Team-Rota [2] - https://github.com/kata-containers/community/wiki/Release-Team-Rota

3 2

reminder: arch committee cancelled this week
by Ernst, Eric 12 Nov '18

12 Nov '18

A large group of us are in Berlin for Openstack Summit, so planned to have this session cancelled. Thanks, Eric

1 0

Heads up: QEMU 3.0 SIGABRT on termination with -daemonize
by Stefan Hajnoczi 10 Nov '18

10 Nov '18

If you use QEMU 3.0 with Kata Containers you might hit a SIGABRT when the QEMU process terminates. This is fixed in QEMU 3.1.0-rc0: https://download.qemu.org/qemu-3.1.0-rc0.tar.xz The fix is QEMU commit 8511770185f5769d06e7c3e37b2fd79f268cf84c ("monitor: delay monitor iothread creation"). Hope this saves you some time! :) Stefan

2 1

kata-agent RemoveContainer timeout buggy?
by Stefan Hajnoczi 09 Nov '18

09 Nov '18

It looks like the goroutine will be left running when kata-agent RemoveContainer() returns after a timeout. In addition, the sandbox lock is no longer held so any actions taken by the goroutine could cause problems. Am I understanding the code correctly? func (a *agentGRPC) RemoveContainer(ctx context.Context, req *pb.RemoveContainerRequest) (*gpb.Empty, error) { ... timeout := int(req.Timeout) a.sandbox.Lock() defer a.sandbox.Unlock() if timeout == 0 { ... } else { done := make(chan error) go func() { if err := ctr.removeContainer(); err != nil { done <- err close(done) return } //Find the sandbox storage used by this container for _, path := range ctr.mounts { if _, ok := a.sandbox.storages[path]; ok { if err := a.sandbox.unsetAndRemoveSandboxStorage(path); err != nil { done <- err close(done) return } } } close(done) }() select { case err := <-done: if err != nil { return emptyResp, err } case <-time.After(time.Duration(req.Timeout) * time.Second): return emptyResp, grpcStatus.Errorf(codes.DeadlineExceeded, "Timeout reached after %ds", timeout) Stefan

2 2

packaging: OBS plans
by Whaley, Graham 09 Nov '18

09 Nov '18

Hi all, We had a conf call yesterday to discuss our packaging plans with the OBS (SUSE) folks yesterday. I'll summarise here with a couple of Actions and the next steps. Attendees: GrahamW, JamesH, MarcoV, FlavioC, CarlosV, ArchanaS Marco put together a presentation, you can find at this link: https://docs.google.com/presentation/d/1lfkElJyOV9hfZY5TFzKuk5Thl_aMyh-xW5W… Fundamentally the plan is to: - move from the current 'home' setup Kata uses to a 'devel' setup to enable supported packaging into openSUSE and SLES. - the devel setup will be maintained by a combination of Kata community members and SUSE employees. - rewrite the specs to be more in line with SUSE standards - Add some method to handle building (or as Carlos' & James other email/Issue - possibly externally build and host) the current binary files - namely the rootfs image. - a possibility here is to use the SUSE 'kiwi' tool. Question: Moving forwards, the Kata community will have to discuss/decide which rootfs image (that is, which distro is the rootfs base upon) to set as the default for the different distro packages. This may be influenced by: - the ability to build some rootfs images from sources/RPMs/kiwi, and others possibly not (DEB or Clear Linux based images maybe) - the 'natural choice' that maybe a distro package would use a rootfs based on the same distro (so SUSE would use a SUSE rootfs, Ubuntu an Ubuntu rootfs etc.) There was some discussion around archiving older versions of packages so users have an option to pin or unwind their installations. There are some methods that may be useable for that in OBS - but, it needs better definition and testing. There was some discussion around how for some distros (say Ubuntu as an example), we need to replace/over-ride the default golang version that comes with the distro to do a build of Kata. Presently we hold binaries in the repo for golang, and that is not acceptable in the official SUSE devel flows. There did seem to be a way to do this better (by adding a sub-package dependency). There was a question if OBS can auto-detect new releases (of Kata), and automatically build. I think the answer is no, it does not do auto change detect/build - but, you can have a 'service file' that wraps the spec file builds and injects version info, so you can have a one-step update/build process (edit the service file and kick off a build), which reduces the burden. Action: We'd like to ensure we do not duplicate any packaging efforts in parallel with other distros - that is, if another distro is already working on packaging Kata, then we do not want to invest too much effort on something that will then be replaced with a formal release from a distro. Julio - can you ascertain the current status and plans for Ubuntu Kata packaging for us please? Action: SUSE would be interested in assessing the Clear Linux optimisations with a vew to applying them to the SUSE rootfs image. Graham to seek out details and contacts (all Clear Linux work is open, and will welcome adoption). Action: Archana had a question about sub-versioning and how users flip versions - we ran out of time. Archana will open a GitHub Issue to ask/discuss. Next step: The plan is to initially write the specs for SUSE in the devel area, and then migrate the other distro builds one at a time from home to devel. Marco and Carlos will work together on the devel scripts (with Marco taking the lead I believe). I'm sure I've missed some finer details. It was a productive meeting and thanks Marco for pushing us along with this :-) 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.

6 10