Re: [atomic-devel] [idea] docker-ostree integrated storage

[Clayton Coleman <ccoleman redhat com>]

----- Original Message -----
> This came up in a discussion elsewhere, just tossing it up on the list if
> anyone's interested:
> 
> > Doesn't this suggest that [Docker sharing] should be independent of the way
> > images are constructed?  This could probably be implemented even today
> > with overlayfs, by keeping a hash file farm and hard-linking that into
> > the immutable base image, similar to what OSTree does.
> 
> The overlayfs backend right now does use hardlinks between base and derived,
> relying on overlayfs copy-up to avoid "hardlink writethrough" - but
> 
> What the above is suggesting is the "hidden ostree-izing" model.  It's
> quite possible.    This would involve something like the overlayfs
> backend being modified to read/write to the host ostree repo.
> 
> It'd be a bit messy as then docker's overlayfs backend would depend
> on an OSTree setup - so it'd probably have to be optional.
> 
> But a neat feature of this model is it would enable sharing with the *host*,
> not just between containers.  For example if you have the exact same
> /usr/lib64/libc-2.17.so or /usr/bin/bash objects in both, which would be
> quite common.
> 
> It would also enable dynamic sharing between independent containers
> that have the same content - this would happen with e.g. new base images
> generated from kickstarts instead of deriving from $distro base.

The idea of managing or generating docker images as atomic trees is also appealing. In the long term being able to fetch content trees in many forms (docker images, rocket ACIs, os-tree composes) and use them in different forms (for the host, for the containers, for local development) has a lot of appeal.