chrismurphy added a new comment to an issue you are following:
``
> dustymabe
> with DOCKER_ROOT_VOLUME and overlayfs using that then all of /var/lib/docker 
> would be taken care of. Please let me know if I'm wrong.

It'll work on a conventional installation. I'm skeptical it'll work on an 
rpm-ostree installation because /var is already a bind mount performed by 
ostree during the startup process. So I'm pretty sure ostree is going to have 
to know about the "true nature" of a separate var partition, mount it, then 
bind mount it correctly.

>I tend to think more about the cloud use case where you spin up a 
>preconfigured image. What I was referring to is having docker-storage-setup be 
>able to make the switch for us.

I don't have a strong opinion on where the proper hinting belongs to indicate 
which driver to use. The user already has to setup #cloud-config so maybe the 
hint belongs in there, and either it does something to storage which is then 
understood by docker-storage-setup, or the hint is just a baton to 
docker-storage-config to do it, just depends on which is more flexible and 
maintainable.

> This means we can essentially look at if the user provided overlay or DM and 
> do whatever they asked.
> - If they provided overlay then we can just extend the root partition and go 
> on our merry way.
> - If they also specified DOCKER_ROOT_VOLUME=yes then they want overlay on 
> another partition, did they specify a partion? yes, use that one. no, create 
> an LV.
> - If they provided DM then create new LVs and set it up just like we have 
> been doing before this discussion started.

Seems reasonable. But I have zero confidence at the moment that ostree can 
handle a separate /var file system; it's a question for Colin what assumptions 
are being made and I think it assumes it's directory that it bind mounts 
somewhere, and if it's really a separate volume, then something has to mount it 
first before it can be bind mounted elsewhere.

An additional trick is testing any changes against Btrfs where mounting 
subvolumes explicitly is actually a bind mount behind the scene. That should 
just work but...
``

To reply, visit the link below or just reply to this email
https://pagure.io/atomic-wg/issue/186
_______________________________________________
cloud mailing list -- cloud@lists.fedoraproject.org
To unsubscribe send an email to cloud-le...@lists.fedoraproject.org

Reply via email to