Gluster users - Jan 2013 - What would the cli command look like for integrating custom xlator?

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?
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://supercolony.gluster.org/pipermail/gluster-users/attachments/20130122/6f01c663/attachment.html>

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.