[Gluster-devel] RFC: Gluster.Next: Where and how DHT2 work/code would be hosted

Jeff Darcy jdarcy at redhat.com
Thu Oct 29 23:29:11 UTC 2015


On October 29, 2015 at 9:12:46 AM, Shyam (srangana at redhat.com) wrote:
> Will code that NSR puts up in master be ready to ship when 3.8 is
> branched?

Do we know when 3.8 will be branched?

> I ask the above, as I think we need a *process*, and not an open ended
> "put it where you want option", for the following reasons, - Something
> that ships experimental is not to be consumed in production, so till
> the point an/any effort is ready it can be housed in experimental - It
> is not about how much of infra code is impacted, or how much code
> would change, it is about readiness of the functionality

I disagree.  From an operational perspective, unavoidable impact (not
just on infrastructure but on any existing functionality) is *the* thing
we want to avoid.  Experimental code that sits on disk, but isn’t even
loaded into memory without an explicit request to enable it, carries
little risk.  Experimental code that’s loaded and executed every time
Gluster is run carries more risk, even if it’s just one line.

> - The intention is also to keep such WIP xlators segregated in master
> - It is easy to control the "don't build/ship" directive for
> everything under experimental, rather than make these decisions at a
> per directory/xlator/module level

They’re likely to make those decisions at the finer granularity anyway.
Most people will probably only want to try out one experimental
translator at a time.  Making them edit two makefiles (to enable
“experimental” and then a specific translator within it) instead of just
one doesn’t seem to get us very far.  Either way they’ll have to edit
the specfile, and they’ll see a list of all the experimental translators
they could enable.

> - It is a clear message for anyone picking up these pieces to deploy
> and play with etc.

If having to edit makefiles and specfiles by hand isn’t enough, there
are other things we could do to send such a clear message.  For example,
we could require a special configure flag or glusterd startup option to
enable management support for experimental features - not just whole
translators but options within existing translators as well.

> Coming to DHT2, irrespective of reason (1) above, all other reasons
> for which NSR can stay outside of experimental holds good for DHT2 as
> well.

Perhaps.  I think that’s pretty clearly true for the DHT2 translator
itself.  For the associated posix changes it’s less clearly true, but
the modified version could go in storage/posix2 as easily as
experimental/posix or experimental/posix2.

IMO the main reason to have an “experimental” directory is one not
mentioned yet - to put them in a separate RPM.  This is not the same as
your “don’t build/ship” point above because they’ll get *built* anyway.
They’ll just be separately installable - or not, for people who aren’t
interested in experimental code.  Then we could combine that with the
special glusterd startup option mentioned above to make the wole process
of enabling or disabling experimental translators pretty seamless.
Install the RPM, tweak the option, and you can use experimental code.
Otherwise you can’t, and you get a nice clear error message if you try.


So, here's what I think we should do (right now - subject to change).

 1. We should create an "experimental" directory, and update makefiles
    accordingly.

 2. The main Gluster 4.0 translators - dht2+posix, nsr* - should go into
    the experimental directory and the specfile should put those
    translators into a new RPM.

 3. All experimental functionality, whether in its own translator or
    otherwise, should be controlled by an option which is off by
    default.

 4. Configuring an experimental feature should require a special
    glusterd flag (plus installation of the experimental RPM).


More information about the Gluster-devel mailing list