Open Stack

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