launchpad-dev team mailing list archive

[Jamu Kakar <jkakar@xxxxxxxx>]

Hi,

First of all, thanks for writing the document in the wiki and pushing
this discussion forward.  It's very exciting and I'm looking forward
to see how this proposal evolves and gets put into practice.

On Wed, May 18, 2011 at 5:53 AM, Michael Hudson-Doyle
<michael.hudson@xxxxxxxxxxxxx> wrote:
> On Wed, 18 May 2011 15:02:45 +1200, Robert Collins <robertc@xxxxxxxxxxxxxxxxx> wrote:
>> > You say that XML-RPC might be a good default choice for a protocol,
>> > which sounds basically sane to me, although the error reporting makes me
>> > want to cry (another lesson from the codehosting experience --
>> > exceptions raised by the createBranch model method get translated to
>> > XML-RPC faults which then get translated to the exceptions the bzrlib
>> > transport API uses).  We can come up with a better convention here like
>> > putting the class name of the exception to raise as the faultString or
>> > something, but then we're going beyond XML-RPC to the extent that you'll
>> > be wanting to use some kind of specialized client rather than stock
>> > xmlrpclib.  This may not be so bad, but it also means that the
>> > underlying protocol isn't very important, it's the Python (or more
>> > generally, RPC I guess) API that's important, and the protocol is a
>> > detail.  I also don't know of a protocol that has what I would consider
>> > good error handling built into it though.
>>
>> I agree with all of this.
>
> Another point that occurred after lunch: for all sorts of reasons,
> accessing a remote service should be explicit in our code (so let's not
> use xmlrpclib.ServerProxy?).  I'm sure you know this in your bones by
> now with all the lazy loading Storm pain :) Implementing everything in
> Twisted and so having deferreds bubble around would acheive this, but is
> probably massive overkill!

I guess the following is jumping to implementation, but I wonder why
we'd be talking about XML-RPC or HTTP for internal connectivity at
all...?  I'm imagine a solution where connections between services are
established with RabbitMQ.  If a template needs to render a bug it
could put a 'get bug #<number>' on a queue and a service that can
provide the data could pull the message off the queue and publish a
result.

A queue based mechanism for connecting services seems like it would
have some nice benefits:

- When you deploy one service you don't have to tell the others how to
  get to it (or do black magic with HAProxy).  They just need to know
  the name of the queue to publish requests on.

- The system will be pull-based instead of push-based.  It would seem
  there's less likelyhood of any one services becoming overloaded,
  because it decides when it is read to handle a request.

- You don't need HAProxy at all, except at the frontend to handle
  external client requests and load balance them across the various
  frontend template and API services you'll be running.

There are probably more benefits, but a queue based mechanism seems
like an obvious choice (though, I haven't thought about it too deeply,
there's surely all kinds of hidden difficulties).

Thanks,
J.