- kata-dev - lists.katacontainers.io

Kata Mission Statement
by Anne Bertucio 16 Jul '18

16 Jul '18

Hi all, On the Architecture Committee call today, I brought up the creation of a mission statement for Kata Containers. The idea of a mission statement is to be a succinct expression of what this project aims to do and any critical principles driving our work. Process: The Zuul community found that this process[1] worked quite well for them. The TL;DR: 1. Generate ideas and share feedback for set time period (they did one week) (open GitHub issue here[2]) 2. The [Kata Arch Committee] and Foundation team have a veto on suggestions (This is to lean on our community leadership and the Foundation marketing team for their expertise in avoiding statements that might come back to bite us later, etc) 3. Run a vote for the final choice if there isn’t a clear winning amongst the community Thoughts? Ideas? [1] http://lists.zuul-ci.org/pipermail/zuul-discuss/2018-May/000394.html <http://lists.zuul-ci.org/pipermail/zuul-discuss/2018-May/000394.html> [2] https://github.com/kata-containers/community/issues/47 <https://github.com/kata-containers/community/issues/47> Anne Bertucio OpenStack Foundation anne(a)openstack.org | irc: annabelleB

1 0

OpenStack Summit Berlin CFP closes in one week: Submit your Kata talks!
by Anne Bertucio 13 Jul '18

13 Jul '18

Hi all, See the note below from Ashlee at OSF about the OpenStack Summit Berlin CFP, which closes in one week. There was lots of good Kata Containers content in the Container Infrastructure track in Vancouver and it’d be great to see that in Berlin! If you gave a Kata talk in Vancouver, it’s okay to submit the same for Berlin. There will be lots of people in Berlin who weren’t in Vancouver and will want to hear about Kata (but also bring your new ideas and topics!). Please let me know if you have any questions about the Summit CFP process or would like someone to look over your CFP before submission. Cheers, Anne ---------------------------------------- Hi everyone, The CFP deadline for the OpenStack Summit Berlin is less than one week away, so make sure to submit your talks <https://www.openstack.org/summit/berlin-2018/call-for-presentations/> before July 18th at 6:59am UTC (July 17 at 11:59pm PST). Tracks: • CI/CD • Container Infrastructure • Edge Computing • Hands on Workshops • HPC / GPU / AI • Open Source Community • Private & Hybrid Cloud • Public Cloud • Telecom & NFV SUBMIT HERE <https://www.openstack.org/summit/berlin-2018/call-for-presentations/> Community voting, the first step in building the Summit schedule, will open in mid July. Once community voting concludes, a Programming Committee for each Track will build the schedule. Programming Committees are made up of individuals from many different open source communities working in open infrastructure, in addition to people who have participated in the past. Read the full selection process here <https://www.openstack.org/summit/berlin-2018/call-for-presentations/selecti…>. Register for the Summit <https://www.eventbrite.com/e/openstack-summit-november-2018-berlin-tickets-…> - Early Bird pricing ends August 21 Become a Sponsor <https://www.openstack.org/summit/berlin-2018/sponsors/> Cheers, Ashlee Ashlee Ferguson OpenStack Foundation ashlee(a)openstack.org <mailto:ashlee@openstack.org>

2 1

Kata on Fedora experiment (modular kernel)
by Stefan Hajnoczi 11 Jul '18

11 Jul '18

Hi, I wanted to share some thoughts after running Kata on Fedora. I built Kata from source and used the Fedora rootfs together with a vanilla modular kernel. This configuration is similar to what I imagine official Fedora RPMs would eventually use, because they probably want to use a stock Fedora kernel instead of building a special monolithic kernel for Kata. The Fedora rootfs was built like this: # KERNEL_MODULES_DIR=/lib/modules/$(uname -r) OS_VERSION=28 ./rootfs.sh fedora My understanding is Kata wants *either* an initramfs or a disk image. Modular kernels typically need to load drivers before they can access the disk, so I opted for the initramfs even though it is several hundred megabytes. The initramfs could probably be shrunk significantly with some work on the Fedora rootfs script. This configuration required several tweaks to get Kata running. I'm not going to create a patch series or send a pull request, because at this stage these are dirty hacks that cannot be merged. But it's likely that other people will encounter these issues, so I'm including them below. Stefan --- * kata-agent assumes initramfs is equivalent to running the agent as init. In our case kata-agent *is* in an initramfs but *not* init, so it calculates the wrong value for noPivotRoot: diff --git a/agent.go b/agent.go index ec01250..182c2de 100644 --- a/agent.go +++ b/agent.go @@ -830,7 +832,7 @@ func realMain() { running: false, // pivot_root won't work for init, see // Documention/filesystem/ramfs-rootfs-initramfs.txt - noPivotRoot: os.Getpid() == 1, + noPivotRoot: true, // TODO check initramfs, not pid=1! kata-agent might have been started by systemd form an initramfs os.Getpid() == 1, subreaper: r, pciDeviceMap: make(map[string]string), deviceWatchers: make(map[string](chan string)), * kata-agent assumes AF_VSOCK should be used if the guest kernel has vsock support. A generic kernel like the Fedora kernel will have AF_VSOCK but that doesn't mean the virtio-serial device should be ignored. Perhaps change the check to see if /dev/virtio-ports/agent.channel.0 is present? diff --git a/channel.go b/channel.go index b4f8977..34ef292 100644 --- a/channel.go +++ b/channel.go @@ -29,25 +29,29 @@ type channel interface { } func newChannel() (channel, error) { + // This is broken, it ignores the virtio-serial agent.channel.0 device + // in favor of AF_VSOCK support, even on systems that are not going to + // use AF_VSOCK but happen to have the drivers installed. + // Check for vsock support. - vSockSupported, err := isAFVSockSupported() - if err != nil { - return nil, err - } - - if vSockSupported { - // Check if vsock socket exists. We want to cover the case - // where the guest OS can support vsock, but the runtime is - // still using virtio serial connection. - exist, err := vSockPathExist() - if err != nil { - return nil, err - } - - if exist { - return &vSockChannel{}, nil - } - } +// vSockSupported, err := isAFVSockSupported() +// if err != nil { +// return nil, err +// } +// +// if vSockSupported { +// // Check if vsock socket exists. We want to cover the case +// // where the guest OS can support vsock, but the runtime is +// // still using virtio serial connection. +// exist, err := vSockPathExist() +// if err != nil { +// return nil, err +// } +// +// if exist { +// return &vSockChannel{}, nil +// } +// } return &serialChannel{}, nil } * The Fedora initramfs and modular kernel rely on udev to load the virtio_console.ko driver. Make sure to start kata-agent *after* the agent device appears. Note this change will break AF_VSOCK if you choose to use that instead of virtio-serial! diff --git a/kata-agent.service.in b/kata-agent.service.in index 861757d..5395047 100644 --- a/kata-agent.service.in +++ b/kata-agent.service.in @@ -2,6 +2,8 @@ Description=Kata Containers Agent Documentation=https://github.com/kata-containers/agent Wants=kata-containers.target +BindsTo=dev-virtio\x2dports-agent.channel.0.device +After=dev-virtio\x2dports-agent.channel.0.device [Service] # Send agent output to tty to allow capture debug logs * Make sure the rootfs has modprobe and udev. Needed by the modular kernel. diff --git a/rootfs-builder/fedora/config.sh b/rootfs-builder/fedora/config.sh index a0ca15a..19fbc7b 100644 --- a/rootfs-builder/fedora/config.sh +++ b/rootfs-builder/fedora/config.sh @@ -14,4 +14,4 @@ PACKAGES="iptables" #Optional packages: # systemd: An init system that will start kata-agent if kata-agent # itself is not configured as init process. -[ "$AGENT_INIT" == "no" ] && PACKAGES+=" systemd" || true +[ "$AGENT_INIT" == "no" ] && PACKAGES+=" systemd systemd-udev" || true

6 8

FYI: containerd shim API v2
by Tim Allclair 06 Jul '18

06 Jul '18

There is a proposal out in the containerd community for a v2 shim API. This API is specifically targeted at enabling VM-based runtimes, so I wanted to make sure folks in the Kata community have a chance to review it and ensure it is a good (compatible) match for the current Kata runtime APIs. https://github.com/containerd/containerd/issues/2426 Thanks!

3 3

Kata Containers 1.1.0
by Venegas Munoz, Jose Carlos 03 Jul '18

03 Jul '18

Welcome to Kata Containers 1.1.0! Kata Containers team is happy to announce the release 1.1.0. These are one of the main changes in Kata Containers: - The kata runtime added support to share PID namespace. - Now the pause and resume commands were fixed. - Initial support for ppc64le was added to Kata Containers. - Fixed vhost issues on attach. See the complete list of changes: https://github.com/kata-containers/runtime/releases/tag/1.1.0 Kata Containers team.

2 1

Community input needed on Arch Committee Elections
by Anne Bertucio 03 Jul '18

03 Jul '18

Hi all, This morning I mentioned getting up an Architecture Committee election process draft for comment. Before we get a draft up, there’s a lot of outstanding questions about what our elections should look like that need community input. Please take a look through this etherpad and jump in with how you think we should run Arch Committee elections: https://etherpad.openstack.org/p/KataArchElections <https://etherpad.openstack.org/p/KataArchElections> Anne Bertucio OpenStack Foundation anne(a)openstack.org | irc: annabelleB

1 0

Want to contribute?
by Hunt, James O 29 Jun '18

29 Jun '18

Hi All, If you're interested in contributing to the Kata Project but don't know where to start, here are some pointers... = TL;DR = The general advice is: - Start small. - If in doubt, raise an issue. - Talk to us! ;) = Read = - https://github.com/kata-containers/documentation/blob/master/install/README… - https://github.com/kata-containers/community/blob/master/CONTRIBUTING.md - https://github.com/kata-containers/documentation/blob/master/architecture.md - https://github.com/kata-containers/documentation/blob/master/Developer-Guid… If something is unclear/missing/wrong, raise an issue so we (or you, if you want) can fix it. = Review = Take a look at some of the PRs that are in the queue: - https://github.com/pulls?utf8=%E2%9C%93&q=is%3Aopen+is%3Apr+org%3Akata-cont… Add comments if you don't understand something. We want the code to be as easy to understand as possible, so asking questions (even "silly questions" aka "questions nobody else though of" or "questions nobody else was brave enough to ask"!) helps to ensure that. = Tackle = Take a look at the "bitesize" and "good first issue" issues: - https://github.com/issues?utf8=%E2%9C%93&q=is%3Aopen+org%3Akata-containers+… - https://github.com/issues?q=is%3Aopen+org%3Akata-containers+label%3Abitesize Add a comment stating that you'd like to have a go. If you don't know how to start, ask for help! Note that multiple people can be assigned to an issue if necessary. = Lurk = Attend Architecture Committee and Working Committee meetings: - https://katacontainers.io/ You don't need to be an architect / programmer / existing contributor to join! ;) Hang out on slack+irc - see below. = Talk = We don't bite - come along and chat on slack/irc and let us know the sorts of things you'd like to get involved in: - https://github.com/kata-containers/community/blob/master/CONTRIBUTING.md#co… = Promote = We'd love to have a regular blog post summarising the "week in Kata". If you'd like to get involved, see: - http://lists.katacontainers.io/pipermail/kata-dev/2018-April/000113.html. = Play = Install Kata and see how it works: - https://github.com/kata-containers/documentation/blob/master/install/README… = Test = We're always looking to increase our test coverage. Each repo has it's own set of unit tests but we keep all other types of tests in it's own repo and all those tests also get run against all PRs for system components: - https://github.com/kata-containers/tests Take a look at the unit-test coverage for, say, the runtime repo and see if you can find a way to increase it: - https://github.com/kata-containers/runtime = Customise = Try building a custom image with osbuilder: - https://github.com/kata-containers/osbuilder = Optimise = Enable full debug ( https://github.com/kata-containers/documentation/blob/master/Developer-Guid…) create a Kata Container and then start analysing the logs. We've got a basic tool called kata-log-parser that can convert the kata log entries to other formats (text, XML, JSON, TOML, YAML, CSV). Along with high-resolution timestamps, the tool also collates all the log entries and calculates time deltas. That isn't quite as good as system level tracing but can give you an indication of which parts of the system might need further investigation: - https://github.com/kata-containers/tests/tree/master/cmd/log-parser = Overcome = Take a look at the limitations doc and see if you can help to chip away at the outstanding issues: - https://github.com/kata-containers/documentation/blob/master/Limitations.md Cheers, James --- https://katacontainers.io/ | https://github.com/clearcontainers Open Source Technology Center Intel Corporation (UK) Ltd. - Co. Reg. #1134945 - Pipers Way, Swindon SN3 1RJ.

1 1

September in-person meeting dates released
by Anne Bertucio 28 Jun '18

28 Jun '18

Hi all, Kata Containers has been allotted space on the Tuesday-Thursday of the OpenStack PTG (September 11-13). If you’re not familiar with the PTG, it is in-person meeting time for projects that live at the OpenStack Foundation. The meeting is for active contributors of the project to get together for focused development time. By the end of the week in Vancouver, we were getting into a good flow with each other and had some good discussions. You can think of the PTG meeting as an extension of this time, minus the distractions of conference sessions and activities. To make this time worthwhile, we need a critical mass from our project to attend. If you are planning to attend (even if you haven’t sorted travel), please add your name to the etherpad [1] so we can ensure we’ll have a good group. Hope many of you are able to make it! [1] https://etherpad.openstack.org/p/KataContainersPTG4 <https://etherpad.openstack.org/p/KataContainersPTG4> [2] https://www.openstack.org/ptg <https://www.openstack.org/ptg> Anne Bertucio OpenStack Foundation anne(a)openstack.org | irc: annabelleB

1 0

Kata September In-Person Meeting
by Anne Bertucio 23 Jun '18

23 Jun '18

Hi all, Please see the note below from Kendall Nelson (OSF staff) regarding the September OSF project meeting in Denver. For Kata, we will have meeting space for approximately 3 days, and presumably there will be some cross-OSF project meetings as well. The success of this time hinges on participation, so I would strongly encourage you to attend if you’re able. In Vancouver, we were able to move through some longstanding topics quickly by being in person, and I’m looking forward to doing more of this in Denver. You can read more about the project meeting at openstack.org/ptg <http://openstack.org/ptg>, or shoot me a note if you have any questions about attending the Kata meeting. If you plan on attending, please drop your name in this etherpad[1]. Cheers, Anne [1] https://etherpad.openstack.org/p/KataContainersPTG4 ----------------------------------------------------------------- Hello Everyone! Wanted to give you some updates on PTG4 planning. We have finalized the list of SIGs/ Groups/WGs/Teams that are attending. They are as follows: Airship API SIG Barbican/Security SIG Blazar Chef OpenStack Cinder Cyborg Designate Documentation Edge Computing Group First Contact SIG Glance Heat Horizon Infrastructure Interop WG Ironic Kata Containers Keystone Kolla LOCI Manila Masakari Mistral Monasca Neutron Nova Octavia OpenStack Ansible OpenStack Charms OpenStack Helm OpenStackClient Operator Meetup Puppet OpenStack QA Oslo Public Cloud WG Release Management Requirements Sahara Scientific SIG Self-Healing SIG SIG- K8s StarlingX Swift Technical Committee TripleO Upgrades SIG Watcher Zuul (pending confirmation) Thierry and I are working on placing them into a strawman schedule to reduce conflicts between related or overlapping groups. We should have more on what that will look like and a draft for you all to review in the next few weeks. We also wanted to remind you all of the Travel Support Program. We are again doing a two phase selection. The first deadline is approaching: July 1st. At this point we have less than a dozen applicants so if you need it or even think you need it, I urge you to apply here[1]. Also! Reminder that we have a finite number of rooms in the hotel block so please book early to make sure you get the discounted rate before they run out. You can book those rooms here[2] (pardon the ugly URL). Can't wait to see you all there! -Kendall Nelson (diablo_rojo) P.S. Gonna try to do a game night again since you all seemed to enjoy it so much last time :) [1] https://openstackfoundation.formstack.com/forms/travelsupportptg_denver_2018 <https://openstackfoundation.formstack.com/forms/travelsupportptg_denver_2018> [2] https://www.marriott.com/meeting-event-hotels/group-corporate-travel/groupC… <https://www.marriott.com/meeting-event-hotels/group-corporate-travel/groupC…> Anne Bertucio OpenStack Foundation anne(a)openstack.org | irc: annabelleB

2 1

What to do about release versioning ?
by Boeuf, Sebastien 23 Jun '18

23 Jun '18

Hi folks, This morning we wanted to release 1.0.1 but held on because of some discussions about the semver semantic not being followed with this 1.0.1 version. The problem here, we have some "sort of" backward compatibility breakage between the runtime and the agent. And for any non compatible release, semver suggest that the new release should bump to the next X version (based on X.Y.Z notation). But before we can answer this, we have to figure out what is that we consider a "breakage". Let me try to explain the different possibility here, starting from an environment where you installed Kata 1.0.0 from packages: First, let's say we introduced a new PauseContainer() command to our agent protocol, this command will have one commit on the agent repo, updating the gRPC protocol and implementing the new feature. This will be followed by a new patch on the runtime to use this new feature, which means we'll have to revendor the new protocol and implement the runtime to rely on it. Now, let's say we bump both runtime and agent repos including those patches to the version 1.0.1, here is the issue we will run into: - The user with Kata 1.0.0 already installed on his system might update the kata-runtime package without updating the VM image containing the agent. And from his perspective, this is fine because he knows about semver semantics and thinks that a kata-runtime 1.0.1 might still work with the VM image container a kata-agent 1.0.0. Unfortunately, this won't work because the kata-runtime will try to call into the new command PauseContainer() that had been introduced, but the agent will have no idea about what this is, and the gRPC will return an error saying this is not a supported/known command. I have a second example, sorry this email is getting long but we have to talk about all cases here... Let's get back to 1.0.0 and say that some changes on both kata-runtime and kata-agent are modifying an existing command CreateContainer(). In this case, this is a more logical breakage since moving one or the other component to the newest version without bumping the other (either kata-runtime 1.0.0 and kata-agent 1.0.1, or kata-runtime 1.0.1 and kata-agent 1.0.0), will end up in functional issues. The second example is what I would call an obvious backward compatibility breakage, but the first one looks still valid to be taken into account. So now, to summarize, we have to agree on what we call a non compatible version that will be translated into a bump to the next X version. And I can see happening a lot of breakage in the future if we include both cases in what is considered as a "breakage", meaning we might end up on version 100.y.z pretty quickly. Numbers are cheap, but here is the status and I/we need some feedback before we can push the pending release (as we don't want to introduce a wrong version number in the history). Thanks, Sebastien

11 11

kata-containers issues when running CRI-O
by Fuentes, Salvador 22 Jun '18

22 Jun '18

Hi all, Recently we have seen issues with the CRI-O tests in our CI. We have recorded some of the failures on https://github.com/kata-containers/tests/issues/361 I have tried to reproduce the failures and these are my findings: - I found that several kernel warnings are being displayed on the kata-proxy log (you can see the warnings on a comment in the issue above). - There seems to be a race condition somewhere because when running cri-o (crictl) commands manually, I cannot reproduce the issue. - The cri-o random failures seem to only appear in Ubuntu 16-04 host machines and the tests that mostly fail are: 6,7,8 and 9. - I am not sure that the cri-o tests failures are 100% related to the kernel warnings. Sometimes the kernel warning occurs, but the tests pass. - It may be related to the storage driver been used: On ubuntu we use devicemapper, and in the fedora and centos we use overlay. If someone can help debugging this, it would be very helpful. As for the CI failures, which are very annoying, an interim action could be to disable the tests 6-9. With this, we can have a stable CI, while we continue investigating the issue. How to reproduce the issue: 1. Update your kata-containers components to the master branch 2. You'll need to install CRI-O 1.10 and the CNI plugins. If you already have the kata-containers/tests repository, you can run: .ci/install_crio.sh .ci/install_cni_plugins.sh 3. Run the tests using kata-containers runtime: In The kata-containers/tests repository, run: export RUNTIME=kata-runtime sudo -E PATH=$PATH make crio 4. Check logs: sudo journalctl -t kata-proxy sudo journalctl -t kata-runtime Thanks, Salvador Fuentes.

1 0

CPU constraint translation to Qemu SMP options
by Edupuganti, Saikrishna 21 Jun '18

21 Jun '18

Hi Team, When translating the K cpu count from Docker/k8s to Qemu options, what is reasoning behind configuring K sockets with 1 core per socket instead of K cores with 1 socket? Did any performance measurements guide this decision? When we bring up kata container with 8 cpus it brings up a VM with (8+1) sockets - kubectl exec -it ubuntu-kata -- lscpu Architecture: x86_64 CPU op-mode(s): 32-bit, 64-bit Byte Order: Little Endian CPU(s): 1 On-line CPU(s) list: 0 Thread(s) per core: 1 Core(s) per socket: 1 Socket(s): 1 kubectl exec -it ubuntu-kata-8cpu-limit -- lscpu Architecture: x86_64 CPU op-mode(s): 32-bit, 64-bit Byte Order: Little Endian CPU(s): 9 On-line CPU(s) list: 0-8 Thread(s) per core: 1 Core(s) per socket: 1 Socket(s): 9 Thanks, Sai

4 5

Kata with AMD Secure Encrypted Virtualization (SEV)
by Larrew, Jesse 20 Jun '18

20 Jun '18

Hi all, The virtualization instructions in the latest AMD EPYC server processors have been enhanced with a memory encryption feature that could provide projects like Kata Containers with unique security capabilities compared to their non-virtualized counterparts. We call this feature Secure Encrypted Virtualization (or SEV) and would be interested in collaborating with the Kata Container community to enable support for containers with encrypted memory. In short, we've added an inline AES engine to our memory controller that encrypts data written to system DRAM and decrypts data read from DRAM. The encryption keys are generated from a TRNG in the onboard AMD Secure Processor (SP) and programmed into the memory controller as needed in a manner that is never visible to software. Additionally, our virtualization instructions have been enhanced to be able to associate a VM ASID with a unique encryption key, so each VM (or container) can keep the contents of its memory confidential from the host and/or other tenant VMs/containers. The guest kernel can choose which pages to encrypt and which to share with the host by setting a bit in the guest page tables, which puts the guest in complete control of the visibility of their data in the cloud. More information can be found in our Memory Encryption whitepaper [1] and in the Architecture Programmer's Manual [2]. Linux kernel support for SEV has been merged into the 4.15 and upcoming 4.16 kernels. OVMF BIOS support has been merged as well. The qemu changes are still being upstreamed, but the patches are available for testing on github [3]. With the above support in place, we have developed a proof-of-concept demo that is based on Clear Containers. Since the Clear Containers project had already done the heavy lifting to run container workloads inside of a VM, it was rather straightforward to add support to encrypt those VMs using SEV. The required changes are summarized below: * Container kernel: - Add SEV support patches from the Linux kernel repo in [3]. - Force virtio to use the DMA API (and hence SWIOTLB) when adding/removing buffers to/from the virtio ring buffer. - SEV requires a memory copy in order to perform the encryption, so zero-copy solutions using DAX for the container initial user space will not work. + Build in a small initramfs to use as the guest kernel initial user space. + Include the updated container agent binary and supporting libs (~14MB total). * Container agent: - Update the agent not to use the pivot_root() method from the initramfs environment, and perform the pivot to the container workload filesystem manually instead. * Container runtime: - Add the new qemu command line options for starting an SEV guest. * Qemu-lite: - Add the SEV support patches from the qemu repo in [3]. With the above changes, we are able to start docker containers inside of SEV-protected VMs: amd@pecanporter:~/src/git$ sudo docker run -ti --runtime sev-runtime busybox sh / # whoami root / # dmesg | grep SEV [ 0.001000] AMD Secure Encrypted Virtualization (SEV) active [ 0.219196] SEV is active and system is using DMA bounce buffers As a check, dumping the contents of a page from the qemu heap reveals plaintext data: amd@pecanporter:~/src/git$ sudo dd if=/proc/$(pgrep qemu)/mem bs=4096 count=1 skip=23058854513 | xxd | tail dd: /proc/38572/mem: cannot skip to specified offset 1+0 records in 1+0 records out 4096 bytes (4.1 kB, 4.0 KiB) copied, 8.8437e-05 s, 46.3 MB/s 00000f60: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 00000f70: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 00000f80: 0000 0000 0000 0000 7100 0000 0000 0000 ........q....... 00000f90: 2f72 756e 2f76 6972 7463 6f6e 7461 696e /run/virtcontain 00000fa0: 6572 732f 706f 6473 2f33 3565 3233 6565 ers/pods/35e23ee 00000fb0: 3330 6466 6237 3266 3135 3730 6265 3432 30dfb72f1570be42 00000fc0: 6665 3165 6331 3366 3331 3332 6138 6133 fe1ec13f3132a8a3 00000fd0: 6463 3336 6463 3131 6235 6365 3837 6236 dc36dc11b5ce87b6 00000fe0: 3437 3930 3736 6339 612f 636f 6e73 6f6c 479076c9a/consol 00000ff0: 652e 736f 636b 0000 0104 0000 0000 0000 e.sock.......... However, any attempt to read the container memory from the host produces only ciphertext: amd@pecanporter:~/src/git$ sudo dd if=/proc/$(pgrep qemu)/mem bs=4096 count=1 skip=34165702144 | xxd | head dd: /proc/38572/mem: cannot skip to specified offset 1+0 records in 1+0 records out 4096 bytes (4.1 kB, 4.0 KiB) copied, 8.9039e-05 s, 46.0 MB/s 00000000: e9b8 e14d c063 ee18 fd85 5ecc 4d1f c1a2 ...M.c....^.M... 00000010: d681 cdf2 259b a97e c43b 5cde bf9e 695b ....%..~.;\...i[ 00000020: db3c 778b 8e77 89f4 f795 e5a6 9ebb 765b .<w..w........v[ 00000030: 0905 e1d3 c7ec 6f2b bada ed15 b2e0 db7f ......o+........ 00000040: d5e9 6d15 cf28 0ca1 4a45 3b9a 1779 e3ff ..m..(..JE;..y.. 00000050: 9ee0 b562 2311 6e5a e972 4c06 3f6a 6ebf ...b#.nZ.rL.?jn. 00000060: 909a 88ea 737a 6226 5d87 8968 b31b d096 ....szb&]..h.... 00000070: 9360 cbb0 4f34 d811 89a7 048f 01e8 d19e .`..O4.......... 00000080: 5429 995a 4de0 6fba 3360 8bb4 a2dc 17e4 T).ZM.o.3`...... 00000090: 80f5 6657 9fd7 0347 e78d 4d13 6b6c c649 ..fW...G..M.kl.I Our threat model is to allow container workloads to reduce their risk exposure to security vulnerabilities in the hosting environment, which seems to overlap nicely with the threat model of Kata Containers. Is this a feature that the Kata community would find useful? If so, we would be very interested to work with the community to enable SEV memory encryption for Kata Containers. Any and all feedback is welcome! Thanks! References: [1] AMD Memory Encryption Whitepaper: http://amd-dev.wpengine.netdna-cdn.com/wordpress/media/2013/12/AMD_Memory_E… [2] AMD64 Architecture Programmer's Manual Volume 2: System Programming: http://developer.amd.com/wordpress/media/2012/10/24593_APM_v21.pdf [3] AMD SEV github repo: https://github.com/AMDESE/AMDSEV Sincerely, Jesse Larrew MTS Software Security Architect AMD Security Architecture R&D jesse.larrew(a)amd.com O: +(1) 512-602-0092 (x50092) M: +(1) 512-791-4852

12 32

RFC: Let's do a 1.0.1 release
by Ernst, Eric 20 Jun '18

20 Jun '18

Hey Carlos, all – I chatted a bit on #kata-dev on it and got +1 from Xu/Wei, but I think it is time we do a 1.0.1 release. We’ve had some good fixes since May 22nd land, including some to issues identified during hackathon in Beijing this week. Can we do a release before end of week (sooner is better of course) for 1.0.1? In a perfect world, we’ll have [1] landed, allowing us to post all of our build artifacts on the github release page. WDYT? Any other bug fixes in flight which we should try to land first? Thanks, Eric [1] - https://github.com/kata-containers/packaging/pull/67

3 3

Read & reply please
by edward 18 Jun '18

18 Jun '18

Hello and good day. My name is Edward, and I am contacting you for partnership by reason of the significance of your Nationality, which concerns claim/transfer of Approximately 21 Million US D0llars ia a fixed deposit account left by a deceased Boss and Friend for onward sharing between you and I in a ratio to be agreed. Kindly get back to me as soon as you receive this email for complete details as time is of the essence giving that we have less than 2 month period to achieve this. Regards Edward.

1 0

Container images for kata deployment - docker ID?
by Ernst, Eric 18 Jun '18

18 Jun '18

Hey ya’ll, I have a PR that I’m finishing testing on @ https://github.com/kata-containers/packaging/pull/65 which will help with deploying kata on k8s, and as a part of it I have a Dockerfile for creating container image with our artifacts for Kata. I think we should have this on Dockerhub, and I wanted to suggest we create an account there, katacontainers. First, is that sane? Second, do we have a general email already that we can use for creating / maintaining these kinds of accounts? -Eric

2 1

Call for volunteers: release and packaging team
by Ernst, Eric 14 Jun '18

14 Jun '18

Kata folk, I want to setup a release and packaging team. It’d be helpful to have a couple of people in each geography to help drive this, and will likely include helping maintain packages for consumption by Canonical/Ubuntu and Redhat/Fedora, as well as the infra/processes around release. Please volunteer yourself or a colleague! Thanks, Eric

3 3

ADP Users Contact List
by Sophie Randell 13 Jun '18

13 Jun '18

Hi, I would like to know if you are interested in acquiring ADP Users Contact List? List Contains: Name, Company's Name, Phone Number, Fax Number, Job Title, Email address, Complete Mailing Address, SIC code, Company revenue, size, Web address etc. All Technology / Companies Partners and Users List, IT decision Makers from Fortune 500 Companies, IT Decision Makers from SME as well. Let me know if you are interested and I will get back to you with the counts and pricing. Regards, Sophie Randell Marketing Executive to opt out, please reply with Leave Out in the Subject Line.

1 0

Call for volunteers: Kata CI / test team
by Ernst, Eric 12 Jun '18

12 Jun '18

Kata folks, I’m excited to have gotten interest for release/packaging. While I have positive momentum, I’ll put out same request with respect to CI / testing. A lot of testing is in place today, though we are scaling to more clouds and more hardware architectures today. Similarly, there’s plenty of work that can be done in the existing CI today to increase test coverage, add more functional tests, and reduce test-time. It’d be helpful to have a couple of people in each geography to help drive this. On the Intel side, I expect Salvador and Gaby to help (located in UTC-5). Please volunteer yourself or a colleague! Thanks, Eric

1 0

osbuilder/rootfs build with docker on native ubuntu host
by Liu, Changcheng 08 Jun '18

08 Jun '18

Hi all, I fail to build rootfs on ubuntu host after following the “rootfs-builder/README.md” guide. Could anyone give me some idea to do further check? Issue: sudo -E ./rootfs-builder/rootfs.sh -r "${PWD}/fedora_rootfs" fedora ~/LINUX/go_repo/osbuilder/rootfs-builder/fedora ~/LINUX/go_repo/osbuilder # # Copyright (c) 2018 Intel Corporation # # SPDX-License-Identifier: Apache-2.0 From fedora:27 RUN dnf -y update && dnf install -y git redhat-release systemd pkgconfig gcc coreutils # This will install the proper golang to build Kata components ADD https://storage.googleapis.com/golang/go1.9.2.linux-amd64.tar.gz /tmp RUN tar -C /usr/ -xzf /tmp/go1.9.2.linux-amd64.tar.gz ENV GOROOT=/usr/go ENV PATH=$PATH:$GOROOT/bin:$GOPATH/bin Dockerfile: /usr/share/man/man5/Dockerfile.5.gz ~/LINUX/go_repo/osbuilder Sending build context to Docker daemon 4.096kB Step 1/6 : From fedora:27 27: Pulling from library/fedora 2176639d844b: Pull complete Digest: sha256:ec588fc80b05e19d3006bf2e8aa325f0a2e2ff1f609b7afb39176ca8e3e13467 Status: Downloaded newer image for fedora:27 ---> 9110ae7f579f Step 2/6 : RUN dnf -y update && dnf install -y git redhat-release systemd pkgconfig gcc coreutils ---> Running in d367d5572325 Error: Failed to synchronize cache for repo 'updates' The command '/bin/sh -c dnf -y update && dnf install -y git redhat-release systemd pkgconfig gcc coreutils' returned a non-zero code: 1 Environment: 1. Host info: lsb_release -a LSB Version: core-9.20160110ubuntu0.2-amd64:core-9.20160110ubuntu0.2-noarch:security-9.20160110ubuntu0.2-amd64:security-9.20160110ubuntu0.2-noarch Distributor ID: Ubuntu Description: Ubuntu 16.04.1 LTS Release: 16.04 Codename: xenial 2. Docker info: sudo -E docker info 2>/dev/null | grep -i 'proxy\|runtime\|version' Server Version: 18.03.1-ce Runtimes: runc Default Runtime: runc containerd version: 773c489c9c1b21a6d78b5c538cd395416ec50f88 runc version: 4fc53a81fb7c994640722ac585fa9ca548971871 init version: 949e6fa Kernel Version: 4.4.0-31-generic HTTP Proxy: http://*********:913/ HTTPS Proxy: https://******:913/ No Proxy: localhost,127.0.0.0/8 sudo docker version Client: Version: 18.03.1-ce API version: 1.37 Go version: go1.9.5 Git commit: 9ee9f40 Built: Thu Apr 26 07:17:20 2018 OS/Arch: linux/amd64 Experimental: false Orchestrator: swarm Server: Engine: Version: 18.03.1-ce API version: 1.37 (minimum version 1.12) Go version: go1.9.5 Git commit: 9ee9f40 Built: Thu Apr 26 07:15:30 2018 OS/Arch: linux/amd64 Experimental: false Regards, Changcheng

3 9

Re: [kata-dev] osbuilder/rootfs build with docker on native ubuntu host
by Liu, Changcheng 07 Jun '18

07 Jun '18

Hi Eric, It seems there's something wrong with DNS. There's one step in creating the centos rootfs: sudo -E docker build --build-arg http_proxy=${http_proxy} --build-arg https_proxy=${https_proxy} -t centos-rootfs-osbuilder rootfs-builder/centos I have to give the proxy address explicitly (e.g. 10.239.0.11:911 instead of abc.xyz.com) or it will fail. Do you know how to check whether this is my server issue or docker-self issue? B.R. Changcheng From: Liu, Changcheng Sent: Thursday, June 7, 2018 12:34 AM To: Ernst, Eric <eric.ernst(a)intel.com>; Hunt, James O <james.o.hunt(a)intel.com> Cc: kata-dev(a)lists.katacontainers.io Subject: RE: [kata-dev] osbuilder/rootfs build with docker on native ubuntu host Hi Eric, I'll give your feedback in the morning (It's a little late in PRC). --Thanks Changcheng From: Ernst, Eric Sent: Wednesday, June 6, 2018 8:59 PM To: Hunt, James O <james.o.hunt(a)intel.com<mailto:james.o.hunt@intel.com>> Cc: Liu, Changcheng <changcheng.liu(a)intel.com<mailto:changcheng.liu@intel.com>>; kata-dev(a)lists.katacontainers.io<mailto:kata-dev@lists.katacontainers.io> Subject: Re: [kata-dev] osbuilder/rootfs build with docker on native ubuntu host Can you see if you can start an Ubuntu container and run apt-get update within the container? It sounds like connectivity to me as well. Docker needs proxy settings separately for inside the container connectivity. Eric On Jun 6, 2018, at 5:32 AM, Hunt, James O <james.o.hunt(a)intel.com<mailto:james.o.hunt@intel.com>> wrote: Hi Changcheng, It looks like it might be a network issue or (possibly?) you happened to run the command when the Fedora repo was being updated (I'm not sure if their repo updates are atomic). Could you try re-running and if that doesn't work, raising an issue with the output of `sudo kata-collect-data.sh` pasted into the github issue? - https://github.com/kata-containers/osbuilder/issues/new Cheers, James 2018-06-06 13:12 GMT+01:00 Liu, Changcheng <changcheng.liu(a)intel.com<mailto:changcheng.liu@intel.com>>: Hi all, I fail to build rootfs on ubuntu host after following the "rootfs-builder/README.md<http://rootfs-builder/README.md>" guide. Could anyone give me some idea to do further check? Issue: sudo -E ./rootfs-builder/rootfs.sh -r "${PWD}/fedora_rootfs" fedora ~/LINUX/go_repo/osbuilder/rootfs-builder/fedora ~/LINUX/go_repo/osbuilder # # Copyright (c) 2018 Intel Corporation # # SPDX-License-Identifier: Apache-2.0 >From fedora:27 RUN dnf -y update && dnf install -y git redhat-release systemd pkgconfig gcc coreutils # This will install the proper golang to build Kata components ADD https://storage.googleapis.com/golang/go1.9.2.linux-amd64.tar.gz /tmp RUN tar -C /usr/ -xzf /tmp/go1.9.2.linux-amd64.tar.gz ENV GOROOT=/usr/go ENV PATH=$PATH:$GOROOT/bin:$GOPATH/bin Dockerfile: /usr/share/man/man5/Dockerfile.5.gz ~/LINUX/go_repo/osbuilder Sending build context to Docker daemon 4.096kB Step 1/6 : From fedora:27 27: Pulling from library/fedora 2176639d844b: Pull complete Digest: sha256:ec588fc80b05e19d3006bf2e8aa325f0a2e2ff1f609b7afb39176ca8e3e13467 Status: Downloaded newer image for fedora:27 ---> 9110ae7f579f Step 2/6 : RUN dnf -y update && dnf install -y git redhat-release systemd pkgconfig gcc coreutils ---> Running in d367d5572325 Error: Failed to synchronize cache for repo 'updates' The command '/bin/sh -c dnf -y update && dnf install -y git redhat-release systemd pkgconfig gcc coreutils' returned a non-zero code: 1 Environment: 1. Host info: lsb_release -a LSB Version: core-9.20160110ubuntu0.2-amd64:core-9.20160110ubuntu0.2-noarch:security-9.20160110ubuntu0.2-amd64:security-9.20160110ubuntu0.2-noarch Distributor ID: Ubuntu Description: Ubuntu 16.04.1 LTS Release: 16.04 Codename: xenial 2. Docker info: sudo -E docker info 2>/dev/null | grep -i 'proxy\|runtime\|version' Server Version: 18.03.1-ce Runtimes: runc Default Runtime: runc containerd version: 773c489c9c1b21a6d78b5c538cd395416ec50f88 runc version: 4fc53a81fb7c994640722ac585fa9ca548971871 init version: 949e6fa Kernel Version: 4.4.0-31-generic HTTP Proxy: http://*********:913/ HTTPS Proxy: https://******:913/ No Proxy: localhost,127.0.0.0/8<http://127.0.0.0/8> sudo docker version Client: Version: 18.03.1-ce API version: 1.37 Go version: go1.9.5 Git commit: 9ee9f40 Built: Thu Apr 26 07:17:20 2018 OS/Arch: linux/amd64 Experimental: false Orchestrator: swarm Server: Engine: Version: 18.03.1-ce API version: 1.37 (minimum version 1.12) Go version: go1.9.5 Git commit: 9ee9f40 Built: Thu Apr 26 07:15:30 2018 OS/Arch: linux/amd64 Experimental: false Regards, Changcheng _______________________________________________ kata-dev mailing list kata-dev(a)lists.katacontainers.io<mailto:kata-dev@lists.katacontainers.io> http://lists.katacontainers.io/cgi-bin/mailman/listinfo/kata-dev -- James --- https://katacontainers.io/ | https://github.com/clearcontainers Open Source Technology Center Intel Corporation (UK) Ltd. - Co. Reg. #1134945 - Pipers Way, Swindon SN3 1RJ. _______________________________________________ kata-dev mailing list kata-dev(a)lists.katacontainers.io<mailto:kata-dev@lists.katacontainers.io> http://lists.katacontainers.io/cgi-bin/mailman/listinfo/kata-dev

1 0

Vulnerability disclosure process and contacts for Kata
by Anne Bertucio 06 Jun '18

06 Jun '18

Hi all, There were some good talks at the Vancouver Summit about the kind of security work the Kata community should be doing. An easy one to cherry pick is having an easily discoverable vulnerability disclosure contact and a public process for how those are handled. In regards to process, an easy place to start would be the OpenStack VMT process[1], and using their assistance to make it applicable to how we work in Kata (specifics are strongly tied to the OpenStack project process right now, but the general process is still applicable to us). Are there people in our community who want to champion this and start up our vulnerability management team? [1] https://security.openstack.org/vmt-process.html <https://security.openstack.org/vmt-process.html> Anne Bertucio OpenStack Foundation anne(a)openstack.org | irc: annabelleB

1 0

Re: [kata-dev] osbuilder/rootfs build with docker on native ubuntu host
by Whaley, Graham 06 Jun '18

06 Jun '18

(sorry about the non-threaded copy - odd attachments messing up my email here...) I mentioned on irc - can you check what your env proxy settings are - it looks like the osbuilder scripts pass on (lower case) http_proxy etc.: https://github.com/kata-containers/osbuilder/blob/a12618811dd715c2d4438ce3c… Soo, if you are maybe using HTTP_PROXY, in your env, maybe this does not work? You could run that script (or whichever script you are running) with 'set -x', to see if those docker command line parameters make it through OK. (and, don't forget, this is a public list - don't post your actual proxy settings here - not the IP addresses/machine names at least ;-) Graham ----------- Hi Eric, I'll give your feedback in the morning (It's a little late in PRC). --Thanks Changcheng From: Ernst, Eric Sent: Wednesday, June 6, 2018 8:59 PM To: Hunt, James O <james.o.hunt(a)intel.com<mailto:james.o.hunt@intel.com>> Cc: Liu, Changcheng <changcheng.liu(a)intel.com<mailto:changcheng.liu@intel.com>>; kata-dev(a)lists.katacontainers.io<mailto:kata-dev@lists.katacontainers.io> Subject: Re: [kata-dev] osbuilder/rootfs build with docker on native ubuntu host Can you see if you can start an Ubuntu container and run apt-get update within the container? It sounds like connectivity to me as well. Docker needs proxy settings separately for inside the container connectivity. Eric On Jun 6, 2018, at 5:32 AM, Hunt, James O <james.o.hunt(a)intel.com<mailto:james.o.hunt@intel.com>> wrote: Hi Changcheng, It looks like it might be a network issue or (possibly?) you happened to run the command when the Fedora repo was being updated (I'm not sure if their repo updates are atomic). Could you try re-running and if that doesn't work, raising an issue with the output of `sudo kata-collect-data.sh` pasted into the github issue? - https://github.com/kata-containers/osbuilder/issues/new Cheers, James 2018-06-06 13:12 GMT+01:00 Liu, Changcheng <changcheng.liu(a)intel.com<mailto:changcheng.liu@intel.com>>: Hi all, I fail to build rootfs on ubuntu host after following the "rootfs-builder/README.md<http://rootfs-builder/README.md>" guide. Could anyone give me some idea to do further check? Issue: sudo -E ./rootfs-builder/rootfs.sh -r "${PWD}/fedora_rootfs" fedora ~/LINUX/go_repo/osbuilder/rootfs-builder/fedora ~/LINUX/go_repo/osbuilder # # Copyright (c) 2018 Intel Corporation # # SPDX-License-Identifier: Apache-2.0 From fedora:27 RUN dnf -y update && dnf install -y git redhat-release systemd pkgconfig gcc coreutils # This will install the proper golang to build Kata components ADD https://storage.googleapis.com/golang/go1.9.2.linux-amd64.tar.gz /tmp RUN tar -C /usr/ -xzf /tmp/go1.9.2.linux-amd64.tar.gz ENV GOROOT=/usr/go ENV PATH=$PATH:$GOROOT/bin:$GOPATH/bin Dockerfile: /usr/share/man/man5/Dockerfile.5.gz ~/LINUX/go_repo/osbuilder Sending build context to Docker daemon 4.096kB Step 1/6 : From fedora:27 27: Pulling from library/fedora 2176639d844b: Pull complete Digest: sha256:ec588fc80b05e19d3006bf2e8aa325f0a2e2ff1f609b7afb39176ca8e3e13467 Status: Downloaded newer image for fedora:27 ---> 9110ae7f579f Step 2/6 : RUN dnf -y update && dnf install -y git redhat-release systemd pkgconfig gcc coreutils ---> Running in d367d5572325 Error: Failed to synchronize cache for repo 'updates' The command '/bin/sh -c dnf -y update && dnf install -y git redhat-release systemd pkgconfig gcc coreutils' returned a non-zero code: 1 Environment: 1. Host info: lsb_release -a LSB Version: core-9.20160110ubuntu0.2-amd64:core-9.20160110ubuntu0.2-noarch:security-9.20160110ubuntu0.2-amd64:security-9.20160110ubuntu0.2-noarch Distributor ID: Ubuntu Description: Ubuntu 16.04.1 LTS Release: 16.04 Codename: xenial 2. Docker info: sudo -E docker info 2>/dev/null | grep -i 'proxy\|runtime\|version' Server Version: 18.03.1-ce Runtimes: runc Default Runtime: runc containerd version: 773c489c9c1b21a6d78b5c538cd395416ec50f88 runc version: 4fc53a81fb7c994640722ac585fa9ca548971871 init version: 949e6fa Kernel Version: 4.4.0-31-generic HTTP Proxy: http://*********:913/ HTTPS Proxy: https://******:913/ No Proxy: localhost,127.0.0.0/8<http://127.0.0.0/8> sudo docker version Client: Version: 18.03.1-ce API version: 1.37 Go version: go1.9.5 Git commit: 9ee9f40 Built: Thu Apr 26 07:17:20 2018 OS/Arch: linux/amd64 Experimental: false Orchestrator: swarm Server: Engine: Version: 18.03.1-ce API version: 1.37 (minimum version 1.12) Go version: go1.9.5 Git commit: 9ee9f40 Built: Thu Apr 26 07:15:30 2018 OS/Arch: linux/amd64 Experimental: false Regards, Changcheng _______________________________________________ kata-dev mailing list kata-dev(a)lists.katacontainers.io<mailto:kata-dev@lists.katacontainers.io> http://lists.katacontainers.io/cgi-bin/mailman/listinfo/kata-dev -- James --- https://katacontainers.io/ | https://github.com/clearcontainers Open Source Technology Center Intel Corporation (UK) Ltd. - Co. Reg. #1134945 - Pipers Way, Swindon SN3 1RJ. _______________________________________________ kata-dev mailing list kata-dev(a)lists.katacontainers.io<mailto:kata-dev@lists.katacontainers.io> http://lists.katacontainers.io/cgi-bin/mailman/listinfo/kata-dev --------------------------------------------------------------------- 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

Re: [kata-dev] osbuilder/rootfs build with docker on native ubuntu host
by Liu, Changcheng 06 Jun '18

06 Jun '18

Hi Jcvenega, Have you hit this issue before? Is it related with proxy configuration? B.R. Changcheng From: Liu, Changcheng Sent: Wednesday, June 6, 2018 8:13 PM To: kata-dev(a)lists.katacontainers.io Subject: osbuilder/rootfs build with docker on native ubuntu host Hi all, I fail to build rootfs on ubuntu host after following the “rootfs-builder/README.md” guide. Could anyone give me some idea to do further check? Issue: sudo -E ./rootfs-builder/rootfs.sh -r "${PWD}/fedora_rootfs" fedora ~/LINUX/go_repo/osbuilder/rootfs-builder/fedora ~/LINUX/go_repo/osbuilder # # Copyright (c) 2018 Intel Corporation # # SPDX-License-Identifier: Apache-2.0 From fedora:27 RUN dnf -y update && dnf install -y git redhat-release systemd pkgconfig gcc coreutils # This will install the proper golang to build Kata components ADD https://storage.googleapis.com/golang/go1.9.2.linux-amd64.tar.gz /tmp RUN tar -C /usr/ -xzf /tmp/go1.9.2.linux-amd64.tar.gz ENV GOROOT=/usr/go ENV PATH=$PATH:$GOROOT/bin:$GOPATH/bin Dockerfile: /usr/share/man/man5/Dockerfile.5.gz ~/LINUX/go_repo/osbuilder Sending build context to Docker daemon 4.096kB Step 1/6 : From fedora:27 27: Pulling from library/fedora 2176639d844b: Pull complete Digest: sha256:ec588fc80b05e19d3006bf2e8aa325f0a2e2ff1f609b7afb39176ca8e3e13467 Status: Downloaded newer image for fedora:27 ---> 9110ae7f579f Step 2/6 : RUN dnf -y update && dnf install -y git redhat-release systemd pkgconfig gcc coreutils ---> Running in d367d5572325 Error: Failed to synchronize cache for repo 'updates' The command '/bin/sh -c dnf -y update && dnf install -y git redhat-release systemd pkgconfig gcc coreutils' returned a non-zero code: 1 Environment: 1. Host info: lsb_release -a LSB Version: core-9.20160110ubuntu0.2-amd64:core-9.20160110ubuntu0.2-noarch:security-9.20160110ubuntu0.2-amd64:security-9.20160110ubuntu0.2-noarch Distributor ID: Ubuntu Description: Ubuntu 16.04.1 LTS Release: 16.04 Codename: xenial 2. Docker info: sudo -E docker info 2>/dev/null | grep -i 'proxy\|runtime\|version' Server Version: 18.03.1-ce Runtimes: runc Default Runtime: runc containerd version: 773c489c9c1b21a6d78b5c538cd395416ec50f88 runc version: 4fc53a81fb7c994640722ac585fa9ca548971871 init version: 949e6fa Kernel Version: 4.4.0-31-generic HTTP Proxy: http://*********:913/ HTTPS Proxy: https://******:913/ No Proxy: localhost,127.0.0.0/8 sudo docker version Client: Version: 18.03.1-ce API version: 1.37 Go version: go1.9.5 Git commit: 9ee9f40 Built: Thu Apr 26 07:17:20 2018 OS/Arch: linux/amd64 Experimental: false Orchestrator: swarm Server: Engine: Version: 18.03.1-ce API version: 1.37 (minimum version 1.12) Go version: go1.9.5 Git commit: 9ee9f40 Built: Thu Apr 26 07:15:30 2018 OS/Arch: linux/amd64 Experimental: false Regards, Changcheng

1 0

Vancouver Summit work days recap
by Anne Bertucio 31 May '18

31 May '18

Hi all, This is going to be a long one, so refill your coffee before reading. Thank you to everyone who came and participate in the in-person work time at the Vancouver Summit. It was great for people to be able to meet—many for the first time—and the in-person time always helps move things forward a little quicker and build those relationships that we can take home. So thank you! For those of you who couldn’t attend, I’ve summarized the major take aways below. Notes were taken on this etherpad <https://etherpad.openstack.org/p/KataVancouverAgenda>[1] throughout the week. Topics below: 1.0 Release 1.0 Post Mortem Release Cadence Exploring Zuul CI Security Collateral/Team 9Pfs Working Committee updates The in-person time we had in Vancouver is very similar to what we would have in Denver in September at the PTG <https://www.openstack.org/ptg>[2]. I’d like to encourage folks to put that on their calendar so we can have more of these conversations. 1.0 Release It’s out! The release was well received by people attending, on social, in the press. People are very excited about this project and to see where we go. See Kata talks from the Summit on openstack.org/videos <https://www.openstack.org/videos/search?search=kata%20containers>[3] 1.0 Post Mortem Overall the first release went well, especially considering that we were all coming together for the first time. Biggest areas for improvement: 1. Documentation: We were rushed to update and review our docs at the end of the release cycle, rather than documenting as we went along. Documentation needs to be a priority, potentially to the point of gating PRs if there’s not documentation, so we don’t find ourselves in the docs crunch again. 2. Feature prioritization agreement: We were using ‘release-gating’, ‘p1’, ‘p2’, etc, but without having agreement about how those were assigned and that those tagged features were the top features, or conversely not following the tags and prioritizing other features that were not critical. Before we dig too much into the 1.1+ work, we need to collectively prioritize and tag features so there’s understanding about what we need to be working on. 3. Maintainer audit: We need to audit who the current maintainer are for each repo, make sure that’s an active list, and make sure our owner files are discoverable. We also need to identify and add more SMEs to the repos. 4. CI system: Our CI system is getting a bit too slow for moving things quickly as we grow. We need to see about running jobs in parallel Release Cadence We agreed that long term, we need to be a time-based release, but we seem to be at a temporary impasse where 1) there are a small handful of nearly-done features that did not make it into 1.0 that might be done very soon 2) we don’t have a good sense of what an appropriate time metric is for us yet. The proposal we arrived at is to temporarily be a feature-based release, decided by the Architecture Committee, to move some of these nearly-done items out the door quickly, but transition to a time-based release in the near future once it becomes more obvious what a reasonable release cadence might look like for us (the transition time to be decided by the Architecture Committee). This proposal could definitely use some input from others who have gotten open source projects off the ground :) Exploring Zuul CI (see Eric Ernst’s ML post for more details) This was an item tabled from February until we met up at the Summit. Funnily enough, the job dependency bug that cropped up during the Summit is exactly what Zuul solves, so it was perfect timing to chat. The big benefits (for us) of Zuul are that 1) Zuul can run sequenced repos gated together 2) It’s a service we wouldn’t have to run ourselves, including the security patches etc that we’re responsible for right now in Jenkins. It gives us a CI system with less work for us! The Zuul team is going to start with the proxy repo to give us a feel of Zuul. They’ll have an Azure driver in the near future (and we agreed to lend some of our credits for testing that), but for now we’ll run it on Vexxhost to demo it. Kata Security Collateral There’s lots of excitement around Kata, but one thing that’s missing is security collateral that people can take to their teams to show that Kata takes security seriously. These are things like data flows, threat models, pen testing, and a dedicated security group within our community to show that we take security seriously. To get this going, I’m hoping our supporting companies can pitch in security team time and resources to help build these items out collectively. Drop us a note if this is you or your org can help—we have potential users standing on the sidelines waiting for this and I think it’s a critical piece of our project’s growth. 9Pfs as our storage solution We talked about this one extensively; it’s a big one! 9P is a limitation for some distros, and might hit performance issues in the future. There’s lots of comments in the etherpad, but what will help drive this forward is better understanding the storage needs of Kata users/potential users. This will help give direction for where “life beyond 9P” should go. If this is you, you can post a note on the ML with your use case and share some insight. Working Committee The Working Committee (marketing, advocacy, community committee) also met in Vancouver. Reflecting on 1.0 reception, we need to be producing content in two categories: 1) Deep dives on Kata—demos, technical details 2) General information on containers security and “why Kata”. On the later, there’s still not enough education out there about the security profile of containers and why a solution like Kata is needed, or what it can help. Conference season is also upon us, and there’s no reason Kata shouldn’t be everywhere! In the WC meeting today, we started this etherpad <https://etherpad.openstack.org/p/KataTalks>[4] to keep track of what conferences people intend to submit to. Please add where you are submitting your Kata talks! We also need to generate a “Kata 101” packet for people who would like to go give Meetup talks, talk at their company, etc. ——— [1] https://etherpad.openstack.org/p/KataVancouverAgenda [2] https://www.openstack.org/ptg [3] https://www.openstack.org/videos/search?search=kata%20containers [4] https://etherpad.openstack.org/p/KataTalks Anne Bertucio OpenStack Foundation anne(a)openstack.org | irc: annabelleB

1 0