From mboxrd@z Thu Jan 1 00:00:00 1970 From: Brad Hubbard Subject: Re: Ideas for new ceph-mgr service Date: Wed, 13 Jan 2016 21:33:05 -0500 (EST) Message-ID: <427576339.11773553.1452738785760.JavaMail.zimbra@redhat.com> References: <156637337.14721161.1452700430079.JavaMail.zimbra@redhat.com> <56969124.4040604@redhat.com> <20160113211536.GA26123@ultraspiritum.redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Return-path: Received: from mx4-phx2.redhat.com ([209.132.183.25]:45898 "EHLO mx4-phx2.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752348AbcANCdH (ORCPT ); Wed, 13 Jan 2016 21:33:07 -0500 In-Reply-To: Sender: ceph-devel-owner@vger.kernel.org List-ID: To: John Spray Cc: Mark Nelson , Matt Benjamin , Ceph Development ----- Original Message ----- > From: "John Spray" > To: "Mark Nelson" , "John Spray" , "Matt Benjamin" , > "Ceph Development" > 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 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@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html >