Bug 902955 - [enhancement] Provide a clear and easy way to integrate 3rd party translators
[enhancement] Provide a clear and easy way to integrate 3rd party translators
Status: NEW
Product: GlusterFS
Classification: Community
Component: cli (Show other bugs)
3.7.6
Unspecified Unspecified
medium Severity unspecified
: ---
: ---
Assigned To: Kaushal
: Reopened, RFE, Triaged
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2013-01-22 14:37 EST by Joe Julian
Modified: 2016-01-11 03:47 EST (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2015-10-22 11:46:38 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Joe Julian 2013-01-22 14:37:15 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.
Comment 1 Jeff Darcy 2013-01-22 14:55:06 EST
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.
Comment 2 Kaleb KEITHLEY 2015-10-22 11:46:38 EDT
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.
Comment 3 Joe Julian 2015-10-22 11:59:14 EDT
Hopefully, this will be part of glusterd 4.0
Comment 4 Joe Julian 2015-12-14 17:34:17 EST
What info is needed?
Comment 5 Joe Julian 2015-12-28 13:32:05 EST
Resetting the needinfo flag as there was no information requested and bugzilla is nagging me.

Note You need to log in before you can comment on or make changes to this bug.