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@xxxxxxxxxxx [gluster-devel-bounces@xxxxxxxxxxx] on behalf of Atin Mukherjee [amukherj@xxxxxxxxxx] Sent: Monday, August 31, 2015 10:04 PM To: Gluster Devel Subject: 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@xxxxxxxxxxx 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 _______________________________________________ Gluster-devel mailing list Gluster-devel@xxxxxxxxxxx http://www.gluster.org/mailman/listinfo/gluster-devel
