Open Stack

On Mon, 2013-04-29 at 12:12 -0400, Doug Hellmann wrote:
> 
> 
> 
> On Mon, Apr 29, 2013 at 12:04 PM, Mark McLoughlin <markmc at redhat.com> wrote:
>         On Mon, 2013-04-29 at 11:44 -0400, Doug Hellmann wrote:
>         >
>         >
>         >
>         > On Mon, Apr 29, 2013 at 11:25 AM, Mark McLoughlin <markmc at redhat.com> wrote:
>         >         On Mon, 2013-04-29 at 10:43 -0400, Doug Hellmann wrote:
>         >         >
>         >         >
>         >         >
>         >         > On Mon, Apr 29, 2013 at 7:00 AM, Mark McLoughlin <markmc at redhat.com> wrote:
>         >         >         On Fri, 2013-04-26 at 15:18 -0400, Doug Hellmann wrote:


>         >         Note, though, this is about a client specifying one of a pool
>         >         of
>         >         listening servers ... it's certainly not a peer of a client,
>         >         and we're
>         >         not talking about peers at the transport level either.
>         >
>         >
>         > Yeah, we still need to figure out what to call that. "Server" is
>         > heavily overloaded, so Eric suggested "peer" as the name of the remote
>         > thing we're talking to.
>         
>         
>         Oh, a peer at transport level, you mean? I'm not sure it makes sense to
>         talk about it generically ... I mean, the only thing that's really
>         important to describe at the transport level with AMQP transport drivers
>         is the broker.
> 
> 
> On the side sending the message we need to know the host where the
> broker is and the host where the server we really want to talk to is
> (the OpenStack service that is going to receive the call and respond
> to it). Instead of calling both of those "host" Eric suggested that we
> call the latter "peer". I don't care what we call it, but "host" isn't
> sufficiently descriptive, IMO.

Ok, fair point. This is the Target::host property currently. I'd just
rename that to Target::server. That reinforces that that Target property
doesn't have any relevance on the server side of the API.

>         
>         > I don't see anything in the current dispatcher that looks like it is
>         > starting an eventlet task, though. Is that happening somewhere else,
>         > or do the individual methods deal with it themselves?
>         
>         
>         It's the consume_in_thread() method on the connection.
> 
> 
> It looks like that is dealing with the reads. How do you envision
> moving that up the stack, and out of the driver?

You need a generic way of saying "spawn a thread to read requests and
dispatch them as invocations on one of these objects" or "block this
thread to read requests and dispatch them as invocations on one of these
objects".

Cheers,
Mark.