> 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 somet

> 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.