[Gluster-users] What would the cli command look like for integrating custom xlator?

[Jeff Darcy]

On 01/22/2013 12:59 PM, Joe Julian wrote:
> The cli has been great for adding the necessary management tools,but if you
> want to use custom translators, you're back to writing vol files and losing
> your ability to do online volume changes. This ability needs to be added in
> order for custom translators to become viable.
>
> What would the cli command look like for integrating custom xlator?
>
> I can picture a couple ways, one of which would be that xlators would list
> requirements and providers so the volgen would be able to intuit a valid graph
> if that xlator is enabled for the volume. The cli would provide command hooks
> for any new features that xlator would need to add to the cli.
>
> The gluster command should have a switch option listing the supported mount
> options in case a xlator provides new ones (would be parsed by mount.glusterfs).
>
> Anybody else have a view?

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.