Red Hat Bugzilla – Bug 902955
[enhancement] Provide a clear and easy way to integrate 3rd party translators
Last modified: 2016-01-11 03:47:28 EST
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.
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:
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.