Re: [Gluster-devel] Proposal for 3.5: Make adding custom translators easy

[Justin Clift]

On 15/08/2013, at 5:51 AM, Anand Babu Periasamy wrote:
> Here are some more points to consider:
> 
>  * gluster-devel package should include all the necessary header and
> library files to compile a standalone glusterfs translator.

That definitely makes sense. :)


>  * /usr/share/doc/gluster-devel/examples/translators/hello-world

"template" might be a better name than "hello-world", just because
it's purpose is then even clearer.

> should contain skeleton translator code (well commented), README.txt
> and build files.  This code becomes the starting point to implement a
> new translator. Make few changes and you should be able to build,
> install, test and package your translator.

Yep, this makes good sense too.


> It is ideal to implement this via script. Similar to autoproject,
> "translator-gen NAME"  should produce all the necessary skeleton
> translator code and associated files.  This avoids erroneous
> find-replace steps.

An approach to automate away the error prone, repetitive setup
stuff makes sense.  Not strictly needed for an initial version of
the feature, but it makes sense if time allows, or in a follow
up version. :)


>  * "Getting Started" documentation, API documentation (including
> libglusterfs APIs)

Yep, definitely required.


>  * Modular GlusterFS CLI API. Today it is hard-coded.

Not so sure about this one.  Allowing for dynamic additions to
the CLI (eg using the meta-data in the JSON fragment) sounds like
a feature of it's own.

Could be a bunch of work in itself, and it's not really a core
requirement.  Like the automated scripting bit, it's probably a
"nice to have" if time allows. :)


>  * Modular volume spec file: each translator should distribute its
> own volume spec snippet and a rule to load (say client only or server
>    only, possible injection points).

Makes sense.  We might find it easier to have different subdirs for
different translator types (eg nfs/ client/ server/ ?).  That could
be over-complicating things though. ;)


>  * Modular documentation API: each translator should describe what it
> does, what options its supports, default values and meaningful range
>    of values.

Interesting. :) The JSON file already has all of that info specified
in it, except for a "description" field, which should be added.


> This doc should be query'ble via gluster CLI

Definitely sounds like part of a "modular CLI" subproject, not part
of this one right away. ;)


> I really hope this initiative gets prioritized for 3.5. We need to
> make it easy for community to contribute translators easily.

Completely agree.  If we get this right, it's a huge enabler to
people customising Gluster how they want + being able to share things
easily. :)

Are you ok with the above item adjustments?  If so, I'll incorporate
them info the Feature page for this.

+ Justin

--
Open Source and Standards @ Red Hat

twitter.com/realjustinclift