[Gluster-devel] The Manila RFEs and why so

[Jeff Darcy]

> As noted, the "Smart volume management" group is a
> singleton, but that single element is tricky. We
> have heard promises of a glusterd rewrite that would
> include the intelligence / structure for such a feature;

I would love to solve this problem for you in 4.0 (which includes
rewrites for at least some parts of glusterd).  Unfortunately, the main
thing blocking progress on 4.0 is the continuing accumulation of 3.x
work.  If there's a "right way" to solve a problem which is only
possible in 4.0, then trying to solve it the "not right way" in 3.x is -
in the long term - a waste of time.  I understand why short-term needs
might dictate that we do it anyway, but whenever it's at all possible we
should try to defer work from 3.x into 4.0 instead of doing it twice.

> also we toyed around implementing a partial version of
> it with configuration management software (Ansible) but
> that was too experimental (the whole concept) to dedicate
> ourselves to it, so we discontinued that.
> 
> OTOH, the directory level features are many but can
> possibly be addressed with a single well chosen volume
> variant (something like lv-s for all top level
> directories?) -- plus the UI would needed to be tailored
> to them.

I don't think auto-provisioning volumes is actually all that hard.  All
we need is a list of places where we can create new directories to be
bricks.  This is not so different from what I did for HekaFS years ago,
and it was one of the easiest parts of the project.  The "gotcha" is
that with lots of tenants we could end up with lots of uncoordinated
glusterfsd processes, with a significant negative impact on performance.
That's why HekaFS had its own infrastructure to generate volfiles and
manage multi-brick daemons.  Such multiplexing is planned for 4.0 but -
again - 4.0 is being delayed by ongoing 3.x work.

Regardless of whether we allocate new shares *within* existing volumes
or *as* new volumes, resizable per-share snapshots and clones are going
to be "interesting" in our LVM-centric snapshot model.  It seems to me
that we'll end up snapshotting a whole LV even when we only intend to
use a tiny portion.  We already have this problem - which results in
wasted space and extra COW activity - somewhat, but it's likely to get
worse under Manila.  Is there something we can do to address it, or is
it just something we'll have to live with?