On 17 Mar 2020, at 18:12, Xu Wang via kata-dev <kata-dev@lists.katacontainers.io> wrote:

Hi folks,

We just discussed some questions about 2.0 in the AC meeting one hour ago and had some initial answers. I post the Q&A here for further discussion and we'd like to make the decision in the next AC meeting.

- Q1: Is the next release is 2.0? or, say, if there is a 1.12.x release before 2.0? (working on 1.12 in parallel is ok for us) - A: We prefer to develop 1.12 and 2.0 in parallel because we think cloud-hypervisor still needs some features to be done.

As I mentioned during the meeting (but with sound issues), there is an effort on identifying various issues with Kubernetes/OpenShift orchestration. This effort is behind some of the issues you have seen coming from Red Hat recently, e.g. libvirt, SElinux, pass-through device mapping, deployment, and so on. In that context, I think that having a 1.12 release where we can iron out some of the wrinkles will be helpful. It would be nice to have 2.0 be the release where all these orchestration aspects connect together.

- Q2: (a) Do we want to support only rust-agent in 2.0? (b) Could we use ttRPC only (no gRPC any more) in 2.0? - (because of rust tool-chain, we might have to disable some un-workable distros as rootfs temporarily when we release 2.0, this is only about the osbuilder and users don't customize there own kata rootfs will not be affected at all)

I would like to understand that one better. There seemed to be an implication that the rust agent would somehow require special system libraries. Or did I understand that wrong? If so, is there an issue tracking this?

- A: Yes. - Q3: Do we want to do the repo consolidation in 2.0 (in kata-containers repo)? - (agent, runtime, shim... into single repo for the convenience of testing/dev) - Q3x: Would that use submodules or straight consolidation? - Ax: plan to be a straight consolidation

Thanks for answering my question. Straight consolidation will clearly require more work / coordination with distro packaging, since it means the old way to get the sources will stop working, and the build instructions will change. Not a biggie, but the reason behind my question.

- A: Yes, we want, however, we may complete this in several releases. - Q4: Should we promote shimv2 as default instead of cmd line? - A: Yes, Samuel thought we should try to remove the legacy shim-v1 support. - docker support v1 only right now, so does Podman - we should work on moby shim-v2 support - at least we think this is not a blocker for 2.0 release - Q5: Should we promote cloud-hypervisor as default in 2.0? - A: Yes, but we still have some ongoing works: - cloud-hypervisor integration: https://github.com/orgs/kata-containers/projects/21

(ref the meeting notes: https://etherpad.openstack.org/p/Kata_Containers_2020_Architecture_Committee...)

Any more ideas?

One aspect that we began discussing last week is how to map resources between the host and the guest. An example is a device or a VF that you hotplug, where the orchestration layer only knows the name of the device in the host. Today, this is passed e.g. using an environment variable, and of course the name is wrong in the guest. Another example is the recent work done on SELinux by Dan Walsh, which raised the problem that we now have changed the semantics of the label. It used to apply to the container, now we also need something that applies to the VM. Unless we add something at the OCI API level to explicitly make the distinction, it looks to me like we need a Kata-specific way to indicate the mapping. I can also imagine things like uid/gid mappings (i.e. what namespaces do for regular containers), filename mappings (e.g. mapping host filenames to virtio_fs mount names), and so on. Unless I’m mistaken, this is is all done on a case-by-case basis for now. For example, you have things like replaceOCIMountSource. The reason for that is obviously that there is some case-specific logic in each scenario. But I have a hunch that a lot could be factored out. Maybe I’m just daydreaming ;-) I really don’t know what I’m talking about yet. I brought that up last week. See also Adrian Moreno’s email for a concrete issue. Thanks, Christophe

Cheers! Xu

-- Xu Wang (@gnawux) Senior Staff Engineer at Ant Financial A Member of Kata Containers Architecture Committee _______________________________________________ kata-dev mailing list kata-dev@lists.katacontainers.io http://lists.katacontainers.io/cgi-bin/mailman/listinfo/kata-dev