<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, Apr 25, 2013 at 11:03 AM, Julien Danjou <span dir="ltr"><<a href="mailto:julien@danjou.info" target="_blank">julien@danjou.info</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div class="im">On Wed, Apr 24 2013, Eric Windisch wrote:<br>
<br>
</div><div class="im">> It gets tricky because ZeroMQ doesn't have "a connection", although I<br>
> suppose it could have different connection profiles (a different port<br>
> number, for instance).<br>
<br>
</div>Well, a "connection" could be something specific to the implementation.<br>
- RabbitMQ (anq qpid I guess) would be host/port/control-exchange<br>
- ZMQ would be host/port<br>
<br>
And each project would use a separate connection to communicate.<br>
<div class="im"><br>
> We have been discussing specifying a message destination as part of<br>
> call/cast instead of topic as presently sent.<br>
><br>
> The new API might be something akin to:<br>
><br>
> dest = rpc.make_destination('compute', host='compute1', cell=CellState)<br>
> rpc.cast(context, dest, msg)<br>
><br>
> # This would replace rpc.cast(context, topic, msg)<br>
> # which would have a check to set topic = dest if not isinstance(RpcDestination, dest)<br>
<br>
</div>That sounds like a good move and handles transition nicely.<br>
I'm not sure about the make_destination() prototype however -- but that<br>
doesn't worry me for now.<br></blockquote><div><br></div><div style>What about making all of those arguments except topic part of the constructor for a Connection, and just instantiating more than one of them to talk to different services?</div>
<div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div class="im"><br>
> Presently, we have various ways of specifying the location of the queues:<br>
> * rabbit_host + rabbit_port + control_exchange (plus auth)<br>
> * qpid_host + qpid_port + control_exchange (plus auth)<br>
><br>
><br>
> * zmq_port + (matchmaker || consumer_host)<br>
> * cell (which maps to some subset of the above)<br>
><br>
> This makes figuring out the proper abstraction for make_destination()<br>
> a bit complex if we want to do anything besides topic and host.<br>
<br>
</div>I see that.<br></blockquote><div><br></div><div style>It seems like the host and port options for rabbit and qpid map to the same values for the matchmaker, don't they? The fact that the actual message doesn't go to the matchmaker is an implementation detail of ZMQ that it can hide.</div>
<div style> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div class="im"><br>
> The ZeroMQ example above is a bit strange, but I wasn't sure how else<br>
> to express it. Basically, we need to lookup some topics in the<br>
> matchmaker, but if we're sending messages to a host directly, we can<br>
> skip that. The code presently knows to send messages to a host by<br>
> delimiting on a period, but it turns out that projects are suddenly<br>
> using periods in topics to delimitate all sorts of other things.<br>
<br>
</div>This is something that could probably be improved in a new version of<br>
the API I presume.<br></blockquote><div><br></div><div style>Right, it seems like the host portion needs to be passed as a separate argument and the AMQP drivers can combine it with the topic, instead of going the other way around.</div>
<div style> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div class="im"><br>
> For ZeroMQ, a control_exchange is effectively a zmq_port *AND* its<br>
> associated matchmaker, which is pluggable. Plugins usually will have<br>
> their own host/port/auth. The MatchMaker basically maintains a mapping<br>
> of topics to consuming peers. Technically, we could lookup all topics<br>
> here, even "compute.host" topics, but we can circumvent a global<br>
> lookup by sending messages directly to "host".<br>
<br>
</div>Understood (because well explained, thanks :)<br></blockquote><div><br class="">How does the ZMQ driver know where the host is without asking the matchmaker? Is that "host" value assumed to be resolvable via DNS?</div>
<div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div class="im"><br>
> Perhaps an rpc-abstraction level concept of a "cell" or "project" is<br>
> needed? That would be an identifier encompassing all the connection<br>
> details (i.e. host/control_exchange, zmq_port/matchmaker), however<br>
> such may be defined for the driver being used?<br>
<br>
</div>That sounds like a good idea to me. That's what I called "connection" in<br>
my previous mail actually. This may be just an abstract class<br>
implemented by each driver in its own way.<br></blockquote><div><br></div><div><div>What defines a "cell" for RPC? Just the alternate host and port for rabbit, qpid, or matchmaker? If so, then the caller just needs to create a new Connection with the right settings, and we don't need to have the concept of "cell" leak into the RPC library API at all. It's there now because we're using a global connection object, but sometimes want to talk to something different. If we stop having a global, the awkwardness will go away and the API can be simpler.</div>
</div><div><br></div><div>Doug</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div class=""><div class="h5"><br>
--<br>
Julien Danjou<br>
# Free Software hacker # freelance consultant<br>
# <a href="http://julien.danjou.info" target="_blank">http://julien.danjou.info</a><br>
</div></div><br>_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br></blockquote></div><br></div></div>