4 ms·

Currently quite a few people from the OCI community (including myself) are working on implementing a CRI-compliant runtime[1] around runC and the various OCI sp

• bogomipz 10y ago
  I am curious how do you manage developing this while the OCI runtime is not yet finalized, do you just make sure they are compliant with the current RC of the spec?
  • mrunalp 10y ago
    The OCI runtime-spec is very close to 1.0. We are just using the rc version for now.
• vidarh 10y ago
  Do you have any more specific pointers regarding using it without a daemon? As the examples seem to start with starting a daemon, unless I misunderstand something. If it doesn't need that, then that's a big plus in my book. Though, I'm getting more and more disillusioned in general with where these specs are heading - the complexity seems to be skyrocketing for sometimes very little benefit. Not necessarily specific to Kubernetes and/or OCI - Docker is a prime offender. E.g. typical example: the highly coupled nature of many of the networking alternatives where routing, fabric and ip allocation gets muddled all up, when there are well developed, stable, well tested independent and orthogonal alternatives for tunnelling and route propagation there's a serious level of Not Invented Here syndrome at work in many of the container projects. I'm sure some people need all the complexity, but I'm getting more and more tempted to ditch many of the higher level tools in favour of composing smaller, simpler tools. (Incidentally I'll make one prediction: one good thing likely to come from CRI is that I suspect it will lead to a new array of Kubernetes "replacements" from simpler composable tools; the APIs don't look all that bad - I just don't like the RPC dependency)
  • cyphar 10y ago
    > Do you have any more specific pointers regarding using it without a daemon? As the examples seem to start with starting a daemon, unless I misunderstand something At the moment, the RPC requirement means that you need to have a process that can accept RPC requests (a "daemon" if you like). However, unlike Docker (and containerd), ocid's lifetime is not tied to the lifetime of its containers -- which is one of the main downsides of Docker/containerd IMO. So in principle you could have ocid set up to only start up when kubelet is telling it to do anything. The real benefit of the design behind ocid is that in the future we could switch to a fork-exec model with the kubelet and it would still work. For example, currently kubernetes is adding a requirement for runtimes to include a "kpod" binary that can do container and image operations even if the kubelet is down. My hope is that eventually they will just make the kubelet shell out to this binary so the CRI is defined through some sort of "here are the cli flags you need to accept" interface. > the complexity seems to be skyrocketing for sometimes very little benefit. I wouldn't call the current CRI "complicated", it's just that the gRPC requirement IMO is a bit too much. However, I would hope that since ocid and rkt both don't require daemons (well, rkt requires systemd but that's a given) that they'll reconsider their method of communicating with container runtime runners.