Re: [atomic-devel] Thinking about CRI-O and Docker on Atomic Host

[Dusty Mabe <dusty dustymabe com>]

On 06/01/2017 03:01 PM, Daniel Walsh wrote:
> On 06/01/2017 01:19 PM, Antonio Murdaca wrote:
>>
>>
>> On Jun 1, 2017 17:58, "Colin Walters" <walters verbum org <mailto:walters 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.

I think we talked about moving to a single / with just overlay by
default for f27 if the overlay by default strategy works out well
for f26.

We also talked about what where docker stores containers vs where
system containers store containers and what to do about that [1].
We need to give some thought to all of this and come up with a 
comprehensive strategy for it. I opened a ticket [2] to track this so
we don't drop the ball on it.

[1] https://lists.projectatomic.io/projectatomic-archives/atomic-devel/2017-April/msg00031.html
[2] https://pagure.io/atomic-wg/issue/281