Deprecating LVM code / commands?

Deprecating LVM code / commands?

[Dave Wysochanski]

I know everyone is focused on features in the next RHEL6 / Fedora, but
have we thought enough about what we could deprecate?  With a major
release around the corner, we don't get this opportunity very often.

For example, do we really need to keep pool and lvm1 formats for the
next 7 years?  If not, we could more easily clean up some of the
internal abstractions.  Other code we could remove that would make
future features / maintenance easier?

Or any LVM commands that should be removed completely?

Note that there is at least 2 approaches:
1) Remove the code completely
2) Deprecate but don't remove

Deprecating LVM code / commands?

[Alasdair G Kergon]

I prefer the bit-rot approach: there are certain parts of the code we no
longer actively maintain and we have no idea whether people are still
using, but as long as nobody reports significant problems it's harmless
to leave them in there.

However, if it turns out that significant work is required in those
areas, that's when we deprecate them by announcing that unless
satisfactory patches are submitted by someone, the code will be gone.

For example, until yesterday I had no idea anyone was still making use
of --disable-o_direct, which was a debugging option I added a long time
ago and I'll happily remove if it gets in the way of some other change we
need.  It remains unmaintained, means pvmove (and probably more things)
can deadlock and really has no place outside a test or development
system.  If O_DIRECT is broken on a system, then please get it debugged
and fixed!

But lvm1 and pool?  Well it's unlikely people are using them on new
systems, but the hard work in offering those formats has already been
done and there's little point in ceasing to support them.  They are
already deprecated in the sense that we regularly add new features that
do not work with those formats.

Is now the time to shift them to a separate compat- sub-package instead
of building them in as a prelude to not installing the package by
default?  Possibly, but that would affect other packages too, so let's
not add to our problems for F11 here - maybe we'll do that in F12 and
meanwhile indicate in RHEL6 that support for lvm1 format will not be
present in RHEL7, assuming RHEL3 is no longer supported by then - we
need to keep it for as long as people might be accessing devices created
on RHEL3 systems.  Upstream however, it should stay pretty much
indefinitely (i.e.  until the next major rewrite).

Alasdair
-- 
agk at redhat.com