Agreed. One other point is containerd isn't a Kubermetes specific runtime. Why cri-o chose to lock in like that doesn't seem to make long term sense except with regard to ease of development.
The long-term goal is to switch users to use podman (and buildah I guess), with cri-o being a daemon that uses the same underlying code. The only reason a daemon is required in the first place is because the CRI uses gRPC.
This is loosely similar to how rkt operated, with rktnetes just being a front-end for rkt (though at the time, the CRI didn't exist so it was all hardcoded in Kubernetes).
The goal isn't to have a differently-named daemon required in order to do any operation, and podman enables that (though again, so did rkt).
Thanks for your insight! I guess I don't understand why having multiple runtimes helps. If CRI is just an agnostic interface to the tooling what is the advantage of cri-o over containerd? Why make the ecosystem harder when it's all a standard runtime interface anyway? Couldn't Docker tooling, podman and buildah all talk directly to any runtime?
This is loosely similar to how rkt operated, with rktnetes just being a front-end for rkt (though at the time, the CRI didn't exist so it was all hardcoded in Kubernetes).
The goal isn't to have a differently-named daemon required in order to do any operation, and podman enables that (though again, so did rkt).