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.
