On 06/01/2017 01:19 PM, Antonio Murdaca wrote:
On Jun 1, 2017 17:58, "Colin Walters" <walt...@verbum.org
<mailto:walt...@verbum.org>> wrote:
I've seen some interesting work on CRI-O for Kube/OpenShift. But
I'm wondering about what people are thinking the future of
docker.service and /usr/bin/docker is (particularly for Atomic Host).
The particular intersection with AH is handling container storage;
AIUI right now you can't have CRI-O and Docker share the same
storage pool.
So...should a CRI-O installer `systemctl stop docker.service;
systemctl mask docker.service`
and reuse the partition we've set up for /var/lib/docker? Or do we
expect people to set up a separate partition?
(It feels like the answer is probably "both")
CRI-O can't actually use the Docker storage transparently. Either you
use skopeo to copy images from Docker to cri-o storage or you start
from scratch.
CRI-O supports "overlay" storage, (Formally overlay2, we have dropped
the old overlay driver). CRI-O storage is in
/var/lib/containers/storage while docker is in /var/lib/docker. They
will not share the same storage, although all of the other container
tools that we are building like skopeo and buildah will be able to share
storage with CRI-O. I am fine with moving to a single / with overlay by
default for both docker and CRI-O.
Perhaps in the big picture for the single-node case we point people
at `oc cluster up` etc? (Which itself should be a system
container probably
to avoid the obvious bootstrapping problem?)
