Open Stack

After conferring with aovchinnikov about the remaining bugs against the 
LXD driver, I have decided that it's better for Manila if we remove the 
driver from the tree before the Mitaka release.

The goal of adding the driver was to create a new, faster, first party 
Manila driver which had proper support for share servers. We need this 
because the generic driver is both slow and somewhat unreliable.

While the LXD driver worked correctly, it never reached the point where 
it was completely stable with high concurrency, and thus didn't meet our 
need for a new driver to use in gate tests.

The following are specific reasons for removing it:

1) The LXD project appears to have an unstable API. We cannot find a 
client version that works with all available releases of LXD and we 
can't find a stable version of LXD to recommend to users. Evidence shows 
that the Manila LXD driver is compatible with LXD 2.0RC2 but not 2.0RC3. 
We can't recommend users run RC2, and if we change the driver to be 
compatible with RC3 we can't guarantee something else won't break with 
some future release. Until the LXD project releases something stable, it 
doesn't make sense to release a Manila driver based upon it.

2) RedHat brought up the issue that LXD is not shipped on all Linux 
distros, and in fact the pylxd library that the driver depends on is not 
even packaged on some distros. As a community we avoid libraries that 
are not widely available, so pylxd was a bad fit here. We implemented 
some workarounds that made the problem less bad for RedHat users, but 
the fact was that the LXD driver was never going to be a good solution 
for RedHat users, unless RedHat was convinced to distribute LXD (which 
is a topic I officially have no opinion about). For this reason we were 
likely to consider replacing the LXD driver with a different 
container-based driver in Newton, and that would have created upgrade 
problems for anyone who actually used the LXD driver in Mitaka. It's 
better to remove it before release to avoid the upgrade issues.


We still retain the option to bring the LXD driver back in Newton, if 
solutions to the above problems can be found -- the code and all 
unmerged bugfixes will be preserved so it can be resubmitted if we 
desire. Alternatively we may implement another container-based driver 
that doesn't suffer from the above problems. If we do that it's likely 
that a majority of the LXD driver code can be reused for that driver.

The problem which the LXD driver was created to solve has not gone away, 
so a solution is still needed in Newton. Personally I'm still very 
optimistic about using containers to solve the problem but we need to be 
more careful about selecting a more stable and widely-supported 
container platform.

-Ben Swartzlander