Open Stack

So this is hard problem to solve without native docker support (which
afaik it doesn't). One potential solution would be to write our own
"named volume" mechanism that will be configurable, after all it's
just bindmounted directory. However it will be hacky and costly to
maintain, although in reality not that much as it's just dirs now
anyway.

So space requirements shouldn't be a problem as nothing prevents you
to mount something to /var/lib/docker/volumes or change docker
directory to something else. Granted, it will put all of docker data
there, but well, depends if that's really a problem. I agree this
should be configurable, but question is if maintaining this non-docker
supported mechanism is worth the benefits it gives.

Cheers,
Michal

On 2 September 2016 at 10:48, Paul Bourke <paul.bourke at oracle.com> wrote:
> Hi Kolla,
>
> We have been experiencing a long running issue with Kolla that I have
> brought up briefly a few times, but not made too much noise about.
>
> I'm taking the time to write about it in the hopes that a) as a community we
> may be able to solve it, and b) if other operators start complaining down
> the line we'll have discussed it.
>
> The issue is that right now all data is stored using named volumes under
> /var/lib/docker. We have encountered users who are not happy with this. As
> well as issues of scale, even with a large /var/ partition this is liable to
> fill up fast, as (in a default setup) it has to store both docker images,
> glance images, nova instance data, and other potentially large files such as
> logs. It's not typical for operators to be expected to store all of this on
> one partition, and doesn't offer the choice expected from a standard (non
> containerised) deploy.
>
> In our Kilo based solution we were solving this using host bind mounts, e.g.
> -v /var/lib/nova:/var/lib/nova, where the directory on the left hand side
> can be mounted wherever you like. Two major issues with this approach are:
>
> 1) Kolla tasks have to be refactored in many places to replace
> "nova_data:/var/lib/kolla" with "/var/lib/nova:/var/lib/nova" (easily
> solvable)
>
> 2) This appears to be incompatible with the 'drop root' work done, as even
> though /var/lib/nova is created and chowned during the build process, it's
> permissions are replaced with those of root when bind mounted from the host.
>
> Other avenues I've explored are seeing the docker volume driver can be
> configured to place data elsewhere (appears not), and symlinking the
> location of the volume to another filesystem as suggested by Michał.
> Symlinking unfortunately also appears to not play well with the Docker
> volume mechanisms.
>
> Do people see this is a potential limitation of Kolla (or maybe Docker?), or
> are we (and our users) being unreasonable in expecting to be able to place
> data on more than one filesystem?
>
> Thanks,
> -Paul
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev