----- Original Message ----- > From: "John Spray" <jspray@xxxxxxxxxx> > To: "Mark Nelson" <mnelson@xxxxxxxxxx>, "John Spray" <jspray@xxxxxxxxxx>, "Matt Benjamin" <mbenjamin@xxxxxxxxxx>, > "Ceph Development" <ceph-devel@xxxxxxxxxxxxxxx> > Sent: Thursday, 14 January, 2016 9:02:57 AM > Subject: Re: Ideas for new ceph-mgr service > > On Wed, Jan 13, 2016 at 9:15 PM, Adam C. Emerson <aemerson@xxxxxxxxxx> wrote: > > On 13/01/2016, Mark Nelson wrote: > > [snip] > >> My gut instinct is to agree with Matt on this one, but I know the pain of > >> trying to develop web services in C++ so I can't get too ornery about it. > >> If there are ways to keep it C++ throughout without too much pain I'd > >> advocate that route. > > [snip] > > > > If the main concern is the annoyance of writing web services, would it make > > sense to use some widely supported binary protocol (Protocol Buffers, Flat > > Buffers, Cap'n Proto, etc.) that can be implemented easily in C++ and is > > well > > supported in Python and other languages? > > When writing our upward-facing interfaces, the #1 goal is low friction > interoperability. REST is essentially the closest thing we have to a > language-agnostic lingua franca. > > To pick up on the examples you mention, Protobuf and Flat buffers are > both just serialization formats, not protocols as such. Cap'n Proto > is an RPC framework, and describes itself as beta, and its RPC as > "particularly experimental". I've spent a fair bit of time in this > space, and there really isn't a more popular or widely supported > protocol for services like this than vanilla REST+JSON. Avoiding the > need for client libraries is key to the usefulness of it, as is the > familiarity and comfort level of third parties we might like to > interact with our API. Something like this then maybe? https://github.com/corvusoft/restbed > > Clearly binary encodings and RPC libraries have a reason to exist: > they are especially useful within systems where both ends are > controlled by the same developers, and performance is important. I'm > a big fan of protobuf, I just don't think it's a good fit here. > > > If we /need/ HTTP and JSON specifically (presumably for someone hacking up > > management software in a web browser's JavaScript runtime) could we have a > > Python translator that just shovels messages from the binary protocol to > > the > > HTTP JSON protocol and back? > > You could, but the resulting HTTP service would not be RESTful. You > can have a "REST API" with an endpoint per RPC call, that only accepts > POSTs (that's what ceph-rest-api is), but it's not really a REST API > (try GET'ing a list of OSDs with ceph-rest-api: it's just not the > model it implements). > > More broadly than the questions of REST vs RPC, or JSON vs protobuf, I > can imagine all kinds of modules someone might drop into this new > service: > * Emit SNMP > * Emit graphite, or influxdb > * Run a simple GUI locally in process > * Fuse the Ceph state with something from another API, like a > hardware status, and serve the result. > * Talk to vendor X's custom protocol for reporting status > > Most of those things would be natural fits for a language like python. > Remember that we're also going to be part of an ecosystem of tools, > including installers, things akin to ceph-deploy, openstack services, > etc etc -- a suitably high level language will make the outward-facing > parts of the code that much more accessible to our non-C++ colleagues. > Using a language that's so widely understood by people doing > integration work is a big win, pragmatically. > > In a way I'm seeking to sidestep the question of the actual protocol: > rather than trying to come up with an all-singing-all-dancing high > performance procotol that is also very easy to consume (there's no > such thing!) I want to create a simple interface from C++ to Python, > so that anyone can readily write a Python module to generate whatever > output or interface they needed between Ceph and their wider > environment. > > I see implementing a REST API in Python as the cheap, low risk option. > I'm not arguing that it's so superior that we should invest lots of > work in it, I'm arguing that it's appealing because of its simplicity > and convenience[1], and if we need to come back with something native > later, we could do that without upsetting the design of the service as > a whole. > > John > -- > To unsubscribe from this list: send the line "unsubscribe ceph-devel" in > the body of a message to majordomo@xxxxxxxxxxxxxxx > More majordomo info at http://vger.kernel.org/majordomo-info.html > -- To unsubscribe from this list: send the line "unsubscribe ceph-devel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
