Lately I have been playing with Ansible at Lilik and I came across a odd behaviour that lately got explained by missing dependencies.

Lilik’s architecture rely on Linux Container to isolate environments and we would really benefit from a playbook to automate containers creation.

This would benefit us because everyone would be able to use the standard issued configuration without typing the long command.

lxc-create -n VM_NAME -t debian -B lvm --vgname VOLUME_GROUP_NAME --lvname L0GICAL_VOLUME_NAME --fstype ext4 --fssize FILESYSTEM_SIZE

So we headed to the Ansible docs and were very pleased to see that the extra modules included a lxc_container module.

In retrospect we should have been more cautious, the module docs explicitly say that only the lxc package is needed but lxc-python2 requires the liblxc package.

lxc >= 1.0 , python >= 2.6, lxc-python2 >= 0.1

We tried the module with a dummy playbook but nothing was happening, the container did not spawn and we couldn’t work it out in that friday afternoon.

During the week Slash digged into the lxc_container module and it discovered something unexpected.

Instead of using only the lxc bindings from Python the module use a mixed approach and produces a shell file that is then executed on the remote host and this shell file contains the command issued by the lxc package.

Turns out that because our version of lxc break liblxc and viceversa we couldn’t run the playbook on localhost.

The module requires python2-lxc and the liblxc bindings on the local machine and the lxc package on the remote host on which you run container. Given that McFly is our local machine and our remote machine there was a conflict and nothing could run.

Lilik container

A simple solution was to reimplement the lxc_container module in pure Python and rely on the liblxc bindings to do the real work. This is not a solution, just a temporary hack until we can have both lxc and liblxc on our beloved machine.

So here we are, the Python implementation is done and available in our repository and today we should test it on the field.

Compared to the official behemoth of ~1.4k lines of code our lilik_container sits at 180 lines of code o it’s obvious that it’s missing something but if we like it more maybe I can work a little more to implement what’s missing, like additional container configuration.

What I really like is that it was trivially easy to implement something that could digest our previous playbook so it is somewhat compatible with the lxc_container module shipped with ansible.