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
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
