<div dir="ltr"><div class="gmail_default" style="font-size:small"><br></div><br><div class="gmail_quote"><div dir="ltr">On Mon, Aug 27, 2018 at 8:56 AM Anne Bertucio <<a href="mailto:anne@openstack.org">anne@openstack.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word;line-break:after-white-space">Hi all,<div><br></div><div>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. </div><div><br></div><div>To kick off Q&A week: <b>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?</b></div></div></blockquote><div><br></div><div><div class="gmail_default" style="font-size:small">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:</div></div><div class="gmail_default" style=""><ol style=""><li style="">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).</li><li style="">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.</li></ol><div>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.</div><div><br></div><div>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).</div><div><br></div><div>As for how to get there, that comes down to policy, best practices, and verification as part of CI.</div><div><br></div><div>Jon</div><div> </div></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word;line-break:after-white-space"><div><b><br></b></div><div>Candidates (in alphabetical order):</div><div>-Eric Ernst [1]</div><div>-Jon Olson [2]</div><div>-Kaly Xin [3]</div><div>-Wei Zhang [4] </div><div><br></div><div><br></div><div>[1] <a href="http://lists.katacontainers.io/pipermail/kata-dev/2018-August/000337.html" target="_blank">http://lists.katacontainers.io/pipermail/kata-dev/2018-August/000337.html</a></div><div>[2] <a href="http://lists.katacontainers.io/pipermail/kata-dev/2018-August/000341.html" target="_blank">http://lists.katacontainers.io/pipermail/kata-dev/2018-August/000341.html</a> </div><div>[3] <a href="http://lists.katacontainers.io/pipermail/kata-dev/2018-August/000333.html" target="_blank">http://lists.katacontainers.io/pipermail/kata-dev/2018-August/000333.html</a> </div><div>[4] <a href="http://lists.katacontainers.io/pipermail/kata-dev/2018-August/000330.html" target="_blank">http://lists.katacontainers.io/pipermail/kata-dev/2018-August/000330.html</a></div><div><br></div><div><br><div>
<div style="color:rgb(0,0,0);letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;word-wrap:break-word;line-break:after-white-space"><div style="color:rgb(0,0,0);letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;word-wrap:break-word;line-break:after-white-space"><div>Anne Bertucio</div><div>OpenStack Foundation</div><div><a href="mailto:anne@openstack.org" target="_blank">anne@openstack.org</a> | irc: annabelleB</div><div><br></div></div><br class="m_4458508906450513699Apple-interchange-newline"></div><br class="m_4458508906450513699Apple-interchange-newline"><br class="m_4458508906450513699Apple-interchange-newline">
</div>
<br></div></div>_______________________________________________<br>
kata-dev mailing list<br>
<a href="mailto:kata-dev@lists.katacontainers.io" target="_blank">kata-dev@lists.katacontainers.io</a><br>
<a href="http://lists.katacontainers.io/cgi-bin/mailman/listinfo/kata-dev" rel="noreferrer" target="_blank">http://lists.katacontainers.io/cgi-bin/mailman/listinfo/kata-dev</a><br>
</blockquote></div></div>