[Gluster-devel] GlusterD 2.0 status updates

[Richard Wareing]

Hey Atin (and the wider community),

This looks interesting, though I have a couple questions: 

1. Language choice - Why the divergence from Python (which I'm no fan of) which is already heavily used in GlusterFS?  It seems a bit strange to me to introduce yet another language into the GlusterFS code base.  Doing this will make things less cohesive, harder to test, make it more difficult for contributors to understand the code base and improve their coding skills to be effective contributors.  I'm a bit concerned we are setting a precedent that development will switch to the new flavor of the day.  If a decision has been made to shift away from Python for the portions of GlusterFS where performance isn't a concern, will the portions currently written in Python be re-written as well?  I also question the wisdom of a language will a shallow developer pool, and a less development process (somewhat of an ironic choice IMHO).

2. RPC framework - What's the reasoning behind using Protocol Buffers vs Thrift?  I'm admittedly biased here (since it's heavily used here at FB), however Thrift supports far more languages, has a larger user-base, features better data structure support, has exceptions and has a more open development process (it's an Apache project).  It's mentioned folks are "uncomfortable" with GLib, exactly why?  Has anyone done any latency benchmarks on the serialization/de-serialization to ensure we don't shoot ourselves in the foot by moving away from XDR for brick<->client/gNFSd communication?  The low latency communication between bricks & clients is to me a _critical_ component to GlusterFS's success; adding weight to the protocol or (worse) making it easier to add weight to me is unwise.

So far things are moving towards 3-4 languages (Python, C, Go, sprinkle of BASH) and 2 RPC frameworks.  No language or RPC mechanism is perfect, but the proficiency of the coder at the keyboard is _far_ more important.  IMHO we should focus on 1 low level high-performance language (C) and 1 higher level language for other components where high performance isn't required (geo-rep, glusterd etc), as it will encourage higher proficiency in the chosen languages and less fractured knowledge amongst developers.

My 2 cents.

Richard


________________________________________
From: gluster-devel-bounces at gluster.org [gluster-devel-bounces at gluster.org] on behalf of Atin Mukherjee [amukherj at redhat.com]
Sent: Monday, August 31, 2015 10:04 PM
To: Gluster Devel
Subject: [Gluster-devel] GlusterD 2.0 status updates

Here is a quick summary of what we accomplished over last one month:

1. The skeleton of GlusterD 2.0 codebase is now available @ [1] and the
same is integrated with gerrithub.

2. Rest end points for basic commands like volume
create/start/stop/delete/info/list have been implemented. Needs little
bit of more polishing to strictly follow the heketi APIs

3. Team has worked on coming up with a cross language light weight RPC
framework using pbrpc and the same can be found at [2]. The same also
has pbcodec package which provides a protobuf based rpc.ClientCodec and
rpc.ServerCodec that can be used with rpc package in Go's standard library

4. We also worked on the first cut of volfile generation and its
integrated in the repository.


The plan for next month is as follows:

1. Focus on the documentation along with publishing the design document
2. Unit tests
3. Come up with the initial design & a basic prototype for transaction
framework.

[1] https://github.com/kshlm/glusterd2
[2] https://github.com/kshlm/pbrpc

Thanks,
Atin
_______________________________________________
Gluster-devel mailing list
Gluster-devel at gluster.org
https://urldefense.proofpoint.com/v1/url?u=http://www.gluster.org/mailman/listinfo/gluster-devel&k=ZVNjlDMF0FElm4dQtryO4A%3D%3D%0A&r=eSXH2j44tGdWnHEbaIk1Tg%3D%3D%0A&m=%2Fqy%2B94CzpNhZn9QOWkfc%2FZkbPJPDiR9uYJNVtG%2BgZPA%3D%0A&s=68e118c111403736815ea0ddf1c756a6c66800a66cbc5e1d14e0586c24ceb695