Hi, Q: What is the most important thing (be it an integration, a particular feature, adopting a policy, etc) Kata Containers needs to achieve in the next year and how should we get there? A: In my opinion, next year will be a year of rapid growth for Kata Containers. The most important thing Kata Containers needs to achieve is to improve the project from 4 aspects in cloud – Orchestration, Compute, Network, Storage. 1. Orchestration: Integration with Kubernetes as much as possible which may generate a mature and usable model in cloud native ecosystem. 2. Compute : Cover the density and general performance profiling, there might be more bugs and improvements to show up. 3. Network: More CNI plugins support and better CNI adoptions. 4. Storage: CSI integration with Kata. For other aspects I could think of: 1. The CI infrastructure/tool to be finalized and stabilized, CI for multi-arch to be supported. 2. Consider new application scenario, for example NFV which could involve both Kubernetes and Kata and try to get new requirement from it. This is an open, friendly community and full of vitality. 😊 We look forward to driving these changes together, so the Kata-containers project can reach its full potential! Thanks Kaly From: Anne Bertucio <anne@openstack.org> Sent: Monday, August 27, 2018 11:56 PM To: kata-dev@lists.katacontainers.io Subject: [kata-dev] [AC] Arch Committee Election: Q&A period open! Hi all, We have four candidates for the Architecture Committee election—names and links to their ML posts below. The next week is for asking questions to candidates via this mailing list; it’s an opportunity to get familiar with the perspective they would bring as an Arch Committee member before voting opens the week of the 3rd. To kick off Q&A week: What is the most important thing (be it an integration, a particular feature, adopting a policy, etc) Kata Containers needs to achieve in the next year and how should we get there? Candidates (in alphabetical order): -Eric Ernst [1] -Jon Olson [2] -Kaly Xin [3] -Wei Zhang [4] [1] http://lists.katacontainers.io/pipermail/kata-dev/2018-August/000337.html [2] http://lists.katacontainers.io/pipermail/kata-dev/2018-August/000341.html [3] http://lists.katacontainers.io/pipermail/kata-dev/2018-August/000333.html [4] http://lists.katacontainers.io/pipermail/kata-dev/2018-August/000330.html Anne Bertucio OpenStack Foundation anne@openstack.org<mailto:anne@openstack.org> | irc: annabelleB 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.

On Mon, Aug 27, 2018 at 8:56 AM Anne Bertucio <anne@openstack.org> wrote:

Hi all,

We have four candidates for the Architecture Committee election—names and links to their ML posts below. The next week is for asking questions to candidates via this mailing list; it’s an opportunity to get familiar with the perspective they would bring as an Arch Committee member before voting opens the week of the 3rd.

To kick off Q&A week: *What is the most important thing (be it an integration, a particular feature, adopting a policy, etc) Kata Containers needs to achieve in the next year and how should we get there?*

I'm going to be a bit boring and also say "stability", in particular interface stability with respect to forward compatibility. From my perspective, this boils down to a couple things: 1. The implicit interface between Kata and the contained workload -- if I take a given workload that uses a fixed feature set and run it under two versions of Kata, the workload should observe an identical execution environment at a POSIX/Linux ABI level. This includes filesystem paths, device paths, network device interface names, etc. Workloads shouldn't take dependencies on these things, but in practice users will create implicit contracts and expect them to be honored. It causes user pain when these things change, which in turn causes operational pain for cluster owners trying to upgrade their infrastructure (be it in a public cloud or a private on-prem installation). 2. The explicit contract between Kata and the on-host orchestration -- a lot here comes from being OCI-compliant, and additional convergence seems among the most valuable things for the project overall, but as others have observed the real surface area is larger. Upgrading Kata within an existing orchestration environment carries similar risks to upgrading Kata around a pre-existing customer workload -- cluster operators will inevitably integrate with any API surface made available, whether or not it is declared to be stable. I would generally put features that address a larger and more diverse set of workloads at lower priority than avoiding regressions for existing workloads. Workloads that are already broken can be frustrating, but at worst they carry an opportunity cost. Breaking running customer workloads across releases (even via a breakage in an implicit rather than explicit contract) causes operational churn in the immediate term, and in the long term it causes a support burden for the Kata community: operators continue using older versions to support existing workloads (whether out of real or merely perceived fear of regressions) and the Kata community ends up with an unwanted long-tail of releases where good community stewardship mandates backporting security fixes, etc. Providing a stable surface area as a first priority and then expanding it in compatible ways allows operators to stay closer to "HEAD" (and in some cases simplifies the maintenance of long-term stable releases). As for how to get there, that comes down to policy, best practices, and verification as part of CI. Jon

Candidates (in alphabetical order): -Eric Ernst [1] -Jon Olson [2] -Kaly Xin [3] -Wei Zhang [4]

[1] http://lists.katacontainers.io/pipermail/kata-dev/2018-August/000337.html [2] http://lists.katacontainers.io/pipermail/kata-dev/2018-August/000341.html [3] http://lists.katacontainers.io/pipermail/kata-dev/2018-August/000333.html [4] http://lists.katacontainers.io/pipermail/kata-dev/2018-August/000330.html

Anne Bertucio OpenStack Foundation anne@openstack.org | irc: annabelleB

_______________________________________________ kata-dev mailing list kata-dev@lists.katacontainers.io http://lists.katacontainers.io/cgi-bin/mailman/listinfo/kata-dev