<p dir="ltr">Resending to mailing list. </p>
<p dir="ltr">---------- Forwarded message ----------<br>
From: "Kaushal M" <<a href="mailto:kshlmster@gmail.com">kshlmster@gmail.com</a>><br>
Date: 03-Aug-2015 10:12<br>
Subject: Re: [Gluster-devel] RPC thoughts for glusterd-2.0<br>
To: "chris holcombe" <<a href="mailto:chris.holcombe@canonical.com">chris.holcombe@canonical.com</a>><br>
Cc: "Krishnan Parthasarathi" <<a href="mailto:kparthas@redhat.com">kparthas@redhat.com</a>></p>
<p dir="ltr">> Hi Chris,<br>
><br>
> In GlusterD-2.0, all the gluster command endpoints will be RESTful<br>
> http api. The gluster cli itself will be a REST client. This should<br>
> allow for easier and better integration for external consumers. We've<br>
> not yet fleshed out the api for all the commands yet. We've started<br>
> off with Heketi's api, which already has it designed for volume<br>
> creation, deletion and listing, and for cluster growth.<br>
><br>
> While the REST api is useful for external consumers, we think it's not<br>
> the most suitable method for doing internal communication within the<br>
> cluster. This is the communication between GlusterD and other<br>
> GlusterDs, bricks, clients etc. We are looking for a good RPC<br>
> framework with libraries for Go and C. There are not a lot around.<br>
> We've looked at 3 so far.<br>
><br>
> 1. gRPC - This is really interesting and provides a lot of features.<br>
> But this is currently in alpha and also requires the use of protobuf3,<br>
> which itself is in alpha.<br>
> 2. Apache Thrift - The C implementation requires the use of Glib,<br>
> which we are not comfortable with and feel is a little too much for<br>
> what we need.<br>
> 3. Json-rpc - This works wonderfully well with Go. But requires a lot<br>
> of manual boiler-plate code writing for C to do the serialization and<br>
> deserialization.<br>
><br>
> We could implement our own sunrpc for Go using go-xdr, but one<br>
> drawback is that, we don't have code generation for Go from .x files.<br>
> This requires us to manually write the request and response structs.<br>
><br>
> We're currently looking at writing our own simple RPC framework using<br>
> protobuf2 for data serialization. Protobuf has a couple of advantages<br>
> over XDR. It's got code-generators for Go and C, and protobuf<br>
> serialized structs are forwards and backwards compatible. Either KP or<br>
> I will be sharing details regarding this soon.<br>
><br>
> If you've got any suggestion, please let us know.<br>
><br>
> And thanks for showing interest in GlusterD-2.0!<br>
><br>
> Cheers,<br>
> Kaushal<br>
><br>
><br>
> On Fri, Jul 31, 2015 at 11:13 PM, Atin Mukherjee<br>
> <<a href="mailto:atin.mukherjee83@gmail.com">atin.mukherjee83@gmail.com</a>> wrote:<br>
> > -Atin<br>
> > Sent from one plus one<br>
> > On Jul 31, 2015 10:57 PM, "chris holcombe" <<a href="mailto:chris.holcombe@canonical.com">chris.holcombe@canonical.com</a>><br>
> > wrote:<br>
> >><br>
> >> Thanks! I'd like to contribute if I can. I found a go xdr library:<br>
> >> <a href="https://github.com/davecgh/go-xdr">https://github.com/davecgh/go-xdr</a><br>
> >> That should be enough to get the sun rpc stuff working. :)<br>
> > +KP,kaushal - this may reduce our effort?<br>
> ><br>
> ><br>
> >><br>
> >><br>
> >> On 07/31/2015 10:26 AM, Atin Mukherjee wrote:<br>
> >>><br>
> >>> Thanks Chris for your mail.<br>
> >>><br>
> >>> We've started exploring different RPC techniques as we plan to write<br>
> >>> glusterd 2.0 in go and it seems like go doesn't have sun RPC library<br>
> >>> support. All the details will be put up once we share the glusterd 2.0 high<br>
> >>> level plan.<br>
> >>><br>
> >>> Having said that, we'd definitely consider your points in terms of<br>
> >>> designing it. Also any form of contribution for glusterd 2.0 Is more than<br>
> >>> welcome :)<br>
> >>><br>
> >>> -Atin<br>
> >>> Sent from one plus one<br>
> >>><br>
> >>> On Jul 31, 2015 10:43 PM, "chris holcombe" <<a href="mailto:chris.holcombe@canonical.com">chris.holcombe@canonical.com</a>><br>
> >>> wrote:<br>
> >>>><br>
> >>>> I've been working on writing a gluster library that speaks the native<br>
> >>>> RPC to gluster so that I could avoid using the CLI. I've been successful<br>
> >>>> but the endeavor has brought up some interesting insights. I plan on open<br>
> >>>> sourcing the code so that everyone can benefit from this.<br>
> >>>><br>
> >>>> struct gf_cli_req {<br>
> >>>> opaque dict<>;<br>
> >>>> };<br>
> >>>> and<br>
> >>>> struct gf_cli_rsp {<br>
> >>>> int op_ret;<br>
> >>>> int op_errno;<br>
> >>>> string op_errstr<>;<br>
> >>>> opaque dict<>;<br>
> >>>> };<br>
> >>>><br>
> >>>> are used to make a lot of the CLI calls. The opaque dict passing back<br>
> >>>> and forth creates a need for string parsing on both sides. My understanding<br>
> >>>> of RPC was that each call would have its own struct associated with it so<br>
> >>>> that no parsing need happen. It would also make it much easier for other<br>
> >>>> people to build libraries to interface with Gluster if the call parameters<br>
> >>>> were clearly defined. Each time I want to make a call work with glusterd<br>
> >>>> 1.0 I need to figure out what parameters need to be packed into the dict.<br>
> >>>> This involves some hunting.<br>
> >>>><br>
> >>>> Since glusterd 2.0 is a refactoring I figured this would be a good time<br>
> >>>> to ask for adding additional more explicit RPC calls to the API. That would<br>
> >>>> make it a breeze to run an rpcgen command against the .x file and have a<br>
> >>>> working library to glusterd!<br>
> >>>><br>
> >>>> Thanks,<br>
> >>>> Chris<br>
> >>>> _______________________________________________<br>
> >>>> Gluster-devel mailing list<br>
> >>>> <a href="mailto:Gluster-devel@gluster.org">Gluster-devel@gluster.org</a><br>
> >>>> <a href="http://www.gluster.org/mailman/listinfo/gluster-devel">http://www.gluster.org/mailman/listinfo/gluster-devel</a><br>
> >><br>
> >><br>
</p>