Hey,
I’m hoping that as a project, we can start sending project updates on the ML on a regular basis (the last ones were posted on 3/11 and 4/6!). With this in mind, I setup a quick rotation to help kick this off for the next few weeks, selecting current architecture committee members as initial volunteers. Please check it out at [1], especially Jon, Wei, Xu and Samuel, whom I volunteered…
Last week there was a good amount of work on refactoring, cleanup, fixups, and (finally!) adding (optional) seccomp support in the guest!
Notable pull requests opened:
* Adding build support for Firecracker
* Kernel version bump
Notable pull requests merged:
* A few pull requests with code cleanup/refactoring from Samuel:
* Simplify the hypervisor interface (runtime #1010)
* Creation of a new internal types package (runtime #1096)
* Sandbox simplification (runtime #1012)
* Add (configurable) seccomp profile support in the guest (runtime #689)
* Handful of fixes / enhancements for containerd v2 shim
Activity:
-Utilizing the latest 1.5.0-rc2 release, a quick demonstration of multiple hypervisor support was created and posted at [2].
-Some members of the community had a follow-up meeting with various open-source groups at AWS, highlighting the current status of Firecracker support in the latest 1.5 release candidate. See [3] for email thread with notes/summary, and find the recording at [5].
-Bergwolf release 1.4.2 release of Kata (stable updates)
Looking forward:
-we are expecting the 1.5 release on 1/23
-Architecture committee meeting moved from Monday mornings at 7am PDT to Tuesdays at 8am PDT. Please feel free to add items to the agenda, [4]. Currently we have discussions on the Denver PTG, CI, CFPs and an overview of work for Kata + Cilium.
Thanks!
-Eric
[1] - https://github.com/kata-containers/community/wiki/Weekly-Update-rotation
[2] - https://asciinema.org/a/219790
[3] - http://lists.katacontainers.io/pipermail/kata-dev/2019-January/000654.html
[4] - https://etherpad.openstack.org/p/katacontainers-2019-architecture-committee…
[5] - https://s3-us-west-1.amazonaws.com/arungupta/Meeting+Recording+-+Firecracke…
Hey folks,
A few of us had the chance to have some follow up discussions with some more members of the AWS firecracker, containers and open source teams.
This was a great chance to meet and talk, highlighting some of the progress the Kata community has made with enabling Firecracker, while also learning more about Amazon’s goals with the Firecracker project. I’m hopeful that next time it can be done in a more open setting. With this in mind, I am starting a working agenda for tasks and topics at the Denver PTG (project team gathering – May 2-4) which coincides with the OpenInfra conference at the beginning of May. This is a great opportunity to meet for a couple of days face to face, without any agenda except what developers want to do for the project: hacking and collaboration. I’ll follow up on this next week.
Please find my rough notes below; I’m hoping to get the recording from the call to share on the mailing list.
Thanks,
Eric
Discussions between Kata + AWS Firecracker/Containers– Jan 11 2019
Attendees:
Eric Ernst
Manohar Castelino
Claire Massey
Arun Gupta
Samuel Ortiz
Adrian Cockroft
Noah Meyerhans
Samuel Karp
Matt Wilson
Meena Gowdar
Actions:
* Eric to provide Arun with estimated Kata+firecracker CI utilization
* Claire to work with Arun on coordination of 1.5 Kata release blog highlighting Firecracker support
* Manohar to prepare and setup agenda item for comparing the containerd and cri-o storage driver interfaces, as a basis for LVM work which could be shared
* Eric to reach out to Sig-Node to discuss next steps on runtimeClass, and in particular around resource management.
* Eric to start a “Kubernetes feature requirements” document, which the greater community (AWS containers team + Kata) can work on as a basis for better defining the scope of Firecracker K8S integration (ie: required, nice-to-have, and planned lack of support).
Notes:
* After general introductions, Eric/Manohar provided an overview / background of status and scope of Kata containers as of 1.5.0-rc2 -- see [1]. Manohar provided a demonstration of Kata + FC + QEMU in K8S (with CRI-O) provided. Most of this is covered in the screen cast at [2]. Support expected to be in the 1.5.0 release, week of January 23rd.
* Kata team to plan on a blog post which can be published with AWS (work with Arun) to highlight release of Firecracker support within Kata.
* From Kata point of view, Firecracker micro-VMM fills a gap that users have expressed around the size and complexity of QEMU. With the hypervisor’s limited feature set, fully featured Kubernetes integration will be out of scope. Kata + firecracker-containers team should jointly create a Kubernetes feature list which can be sorted as required-features, nice to have, and planned lack of support. With this in place, feature requests and issues with relative priority can be opened on the Firecracker GitHub, and where applicable we can work with the Kubernetes community.
* Highlighting admission controller work which has been utilized for effectively enabling Kata in a cluster with multiple runtime classes.
* Kata + Firecracker Continuous Integration on bare-metal: Kata team would like to make sure Firecracker integration with Kata is well tested, including on AWS cloud. We are adding today for nested-virtualization nodes, but would like to also make use of AWS. Action: Eric to follow up with CI load estimation for the current suite of Kata tests.
* Kata project has some group/namespace utilization on the host, but has had some gaps with respect to fully constraining the hypervisor, and have been looking at libvirt and home-grown solutions. Jailer looks very attractive, and is the “right level” of complexity and utility we’ve been looking for. We’ll start taking a look at using this irrespective of the hypervisor (currently will have gaps due to default vhost for networking when utilizing QEMU). This will probably land post 1.5 (schedule 1/23).
* Snapshotter: A great place for immediate, direct collaboration. Since docker/containerd support for devicemapper dropped, AWS team has been working on implementing block based snapshotters to fit into containerd’s snaphotter interface. Having had discussions during CRI-O contributors call, we have an opportunity to collaborate on creating an LVM based snapshotter. Action: Manohar - add CRI-O, containerd snapshotter interface comparison to Kata Arch Committee meeting, [3], and use as basis for starting LVM work. Kata folks to test existing firecracker-containers team’s snapshotters.
* General discussion on solution complexity: Similar to prior discussions, some good highlights into the design principles of Firecracker Hypervisor: reduced feature set by design to achieve an appropriate security profile. On Kata Containers, while adding firecracker support was relatively straightforward, it did highlight some areas where we can reduce features and configuration options. Based on this, Kata is starting to become more opinionated to help reduce complexity. You can track a lot of this in [4]. Suggestions, comments and PRs welcome :)
* Discussions around production use of Kata Containers: There’s a lot of activity right now, and expected a few new users in production in Q1. Over the next couple of months, there should be a lot more that can be highlighted in this space.
* Discussion on resource management work to look at in short term: There are some gaps in the initial implementation of runtimeClass in Kubernetes today. One example is a lack of insight into overheads introduced by runtime implementations, which requires workarounds to make sure node resources available are calculated accurately. Would be good to see if developers from the Kata community can help with some of the features in consideration at sig-node.
* Kata currently leverages the swagger API to interface with Firecracker. Work is currently under way to migrate to the Go SDK for FC, and augment where needed (in particular, the block device rescan support Kata utilizes to mimic hotplug).
* Highlighted the gRPC API utilized for interfacing with the guest agent, kata-agent. Other projects have looked at re-using this interface - may be a good for the firecracker-containerd team to review.
* Discussion on aligning firecracker-containerd work with what is being developed today in Kata Containers. This is still an open on the Amazon side, though there has been good collaboration to date, including common problem areas (see snapshotter notes).
* Many CFPs (OSCON, OpenInfra, KubeCon, ONS) are closing in the next two weeks: pick a couple to highlight the work that has been done to date. See [5].
[1] - https://drive.google.com/file/d/1aEzHHesNoVsZOqK-IIP0g2bbPIRw48Ev/view
[2] - https://asciinema.org/a/219790
[3] - https://etherpad.openstack.org/p/katacontainers-2019-architecture-committee…
[4] - https://github.com/kata-containers/runtime/issues/1113
[5] - https://etherpad.openstack.org/p/KataTalks2019
Good morning.
This weeks herders are ... me :-)
https://github.com/kata-containers/community/wiki/Review-Team-Rota#the-rota
We are sat at 62 open PRs across the repos.
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.
The vsock core only supports 32bit CID, but the Virtio-vsock spec define
CID (dst_cid and src_cid) as u64 and the upper 32bits is reserved as
zero. This inconsistency causes one bug in vhost vsock driver. The
scenarios is:
0. A hash table (vhost_vsock_hash) is used to map an CID to a vsock
object. And hash_min() is used to compute the hash key. hash_min() is
defined as:
(sizeof(val) <= 4 ? hash_32(val, bits) : hash_long(val, bits)).
That means the hash algorithm has dependency on the size of macro
argument 'val'.
0. In function vhost_vsock_set_cid(), a 64bit CID is passed to
hash_min() to compute the hash key when inserting a vsock object into
the hash table.
0. In function vhost_vsock_get(), a 32bit CID is passed to hash_min()
to compute the hash key when looking up a vsock for an CID.
Because the different size of the CID, hash_min() returns different hash
key, thus fails to look up the vsock object for an CID.
To fix this bug, we keep CID as u64 in the IOCTLs and virtio message
headers, but explicitly convert u64 to u32 when deal with the hash table
and vsock core.
Fixes: 834e772c8db0 ("vhost/vsock: fix use-after-free in network stack callers")
Link: https://github.com/stefanha/virtio/blob/vsock/trunk/content.tex
Signed-off-by: Zha Bin <zhabin(a)linux.alibaba.com>
Reviewed-by: Liu Jiang <gerry(a)linux.alibaba.com>
---
drivers/vhost/vsock.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/vhost/vsock.c b/drivers/vhost/vsock.c
index bc42d38ae031..3fbc068eaa9b 100644
--- a/drivers/vhost/vsock.c
+++ b/drivers/vhost/vsock.c
@@ -642,7 +642,7 @@ static int vhost_vsock_set_cid(struct vhost_vsock *vsock, u64 guest_cid)
hash_del_rcu(&vsock->hash);
vsock->guest_cid = guest_cid;
- hash_add_rcu(vhost_vsock_hash, &vsock->hash, guest_cid);
+ hash_add_rcu(vhost_vsock_hash, &vsock->hash, vsock->guest_cid);
mutex_unlock(&vhost_vsock_mutex);
return 0;
--
2.19.1.856.g8858448bb
Hi everyone,
Happy New Year! We'll have a Kata Architecture Committee meeting next Monday, January 7, at the usual time of 7:00am PST. You can join at: https://zoom.us/j/837139405 <https://zoom.us/j/837139405>.
The agenda and notes for the 2019 calls can be found in this new pad: https://etherpad.openstack.org/p/katacontainers-2019-architecture-committee…. Please add any topics you’d like to cover.
Starling the week of January 14, we may want to change the day and/or time for the weekly meetings. If you plan to regularly attend the Architecture Committee calls please take this poll to help us pick the best time(s):
https://framadate.org/katacontainers2019ac
Please complete it by January 9.
Thanks,
Claire
Hi Kata-folk,
In addition to GitHub, Kata development relies on an external service,
PullApprove, in order to process PRs. This external service used to be
free-as-in-beer, but they recently decided[1] to change their terms of
service so that if "people who work on the repository get paid to do so,
then we need to get paid too". They are planning to flip the switch on
February 1, 2019.
Our read of their unclearly-specified conditions to apply for a free
plan concludes that we almost certainly would not qualify: despite the
project being open source and run by a non-profit Foundation, most of
the "people who work on the repository" get paid to do so.
We could of course comply with their reasonably-priced new terms (and
wait for the next bait-and-switch), but as an open source development
best practice it is generally better to reduce our dependency on such
external services, to avoid having the project be negatively affected by
the decisions of a third-party service provider.
Which is why I'm raising this thread, to tap the collective Kata mind
for solutions. In order of decreasing preference, we would find an
alternative solution that would
1- be open source, so that we could actually not depend on an additional
external service provider, or at least have the option to switch to
running it ourselves in case of sudden ToS changes
2- use built-in features of an external service we are already depending
on (GitHub)
3- use a free-as-in-beer external service provider that has already
published clear conditions for open source projects or projects run by
non-profit Foundations
Thoughts ?
[1] https://medium.com/dropseed/changes-to-our-free-plans-2660423c3f6
--
Thierry Carrez (ttx)
Good morning,
Herders this week are James and Rico.
https://github.com/kata-containers/community/wiki/Review-Team-Rota#the-rota
It feels like most folks are back from the vacation period now.
We have **62** open PRs I will note, that is trending UPWARDS. 17 of those are DNM.
I think we can attribute some of this rise to:
- the holiday season
- the project generally being more busy
- the difficulty and size of some of the PRs is increasing...
But, having said that, we do need to keep an eye on this and not allow the number of open PRs to escalate too far.
(to that end, I for one will see if I can visit some of my long standing PRs and nail them or close them...)
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.
Good morning - and *Happy New Year* :-)
I've updated the kat herder table over at:
https://github.com/kata-containers/community/wiki/Review-Team-Rota#the-rota
For the next 9 weeks or so (that seems to be our current rota cycle rate...).
The table contents are below - please.....
* check you are OK to do any weeks your name falls into
* add yourself into as many weeks as you like!
And remember - this is open to *anybody* - if you want to help out reviewing Kata pull requests, then just dive in. You don't have to be an expert or experienced - sometimes feedback is as simple as noting typos or CI failures or nudging folks on stale PRs that seem to be stuck, not moving, under-loved and maybe just forgotten.
| YYYY-MM-DD | APAC | EMEA | AMER | Notes
| ---------- | --------------------| ---------------------------- | ------------------------ |--------
| 2019-01-07 | | [jodh-intel] | [raravena80] | |
| 2019-01-14 | | [grahamwhaley] | | |
| 2019-01-21 | [bergwolf] | [jodh-intel] | [amshinde] | |
| 2019-01-28 | | [marcov] | [devimc] | |
| 2019-02-04 | [ydjainopensource] | | [raravena80] | |
| 2019-02-11 | | | [jcvenegas] | |
| 2019-02-18 | [caoruidong] | | [sboeuf] | |
Many thanks to all our herders - and may our 'flock' continue to thrive through 2019...
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.
Good morning Kat'ers,
As I'm sure you are all aware, we have just about entered the holiday season.
In theory, the official herders according to https://github.com/kata-containers/community/wiki/Review-Team-Rota#the-rota
Are...
Carlos, along with some Elves, Reindeer and maybe Santa himself if he gets his rounds done...
In reality, I suspect we will have no focused herders until maybe January the 2nd onwards... so... no matter where you are or what your plans are, I hope you all have a great break, and will see you back at the keyboard in the new year!
Graham (and the rest of the Herders...)
---------------------------------------------------------------------
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.