Description of problem: Third party translators are one of the clear benefits to the structure that GlusterFS is built on. Some 3rd party translators already exist (miss caching, hekafs xlators, BD) but cannot be integrated without editing vol files which defeats the administrative abilities of glusterd. There needs to be a clearly defined process to add 3rd party xlators to the stack, test those 3rd party xlators for specific compliances, and allow those xlators to extend the cli commands.
From email... How about this? gluster volume client-xlator myvol encryption/rot14 cluster/distribute This would tell the volfile-generation machinery that it should insert something like this: volume myvol-dht type cluster/distribute ... subvolume volume myvol-rot14 type encryption/rot14 ... subvolumes myvol-dht end-volume Basically the type/path is determined by the first argument, and the position in the volfile by the second. There'd be a server-xlator equivalent, obviously, and it's up to you to make sure the translator even exists at that location on each client/server. Then you could do this: gluster volume set myvol encryption/rot14.algorithm Salsa20 This covers most of the kinds of translator insertion that I've seen both in GlusterFS and in HekaFS, though there are a few that require deeper changes to the volfile-generation logic (e.g. when NUFA was brought back or to do HekaFS multi-tenancy). One could even have gluster/d inspect the named .so and make sure that everything "looks right" in terms of entry points and options. One thing I don't like about this approach is that there's no way to specify a specific instance of the new translator or its parent either in the original insertion command or when setting options; there's sort of an implicit "for each" in there. In some situations we might also want separate "above" and "below" qualifiers to say where the new translator should go. For HekaFS I actually developed a Python infrastructure for working with volfiles (see volfile.py either there or in some of my subsequent scripts), and there's a hook to enable them (see volgen_apply_filters). That provides total flexibility, but that doesn't make it the right approach. For one thing, it doesn't really play well with the rest of our option-setting machinery. I think the more "structured" approach would be better for the vast majority of cases, with this type of filter only as a last resort.
because of the large number of bugs filed against mainline version\ is ambiguous and about to be removed as a choice. If you believe this is still a bug, please change the status back to NEW and choose the appropriate, applicable version for it.
Hopefully, this will be part of glusterd 4.0
What info is needed?
Resetting the needinfo flag as there was no information requested and bugzilla is nagging me.
This bug is getting closed because GlusteFS-3.7 has reached its end-of-life. Note: This bug is being closed using a script. No verification has been performed to check if it still exists on newer releases of GlusterFS. If this bug still exists in newer GlusterFS releases, please reopen this bug against the newer release.
Joe, while this has been a valid request, we couldn't get to implement this with GD1 (and later tried it with GD2 as template based volgen). With current scope of things, we are not considering it at the moment. Closing it as DEFERRED, so we can revisit at these after couple of more releases, depending on the capacity.