Open Stack

On Mon, Aug 27, 2018 at 8:56 AM Anne Bertucio <anne at 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 at openstack.org | irc: annabelleB
>
>
>
>
>
> _______________________________________________
> kata-dev mailing list
> kata-dev at lists.katacontainers.io
> http://lists.katacontainers.io/cgi-bin/mailman/listinfo/kata-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.katacontainers.io/pipermail/kata-dev/attachments/20180831/824aa71b/attachment.html>