Open Stack

> On 17 Mar 2020, at 18:12, Xu Wang via kata-dev <kata-dev at 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_Mtgs)
> 
> 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 at lists.katacontainers.io
> http://lists.katacontainers.io/cgi-bin/mailman/listinfo/kata-dev