> 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? _______________________________________________ Gluster-devel mailing list Gluster-devel@xxxxxxxxxxx http://www.gluster.org/mailman/listinfo/gluster-devel
