Open Stack

On Wed, Apr 24 2013, Eric Windisch wrote:

Hi Eric,

> Basically, the fact that one can deploy each project on a different port
> number with ZeroMQ is as close an equivalent (and best practice) as one may
> get to AMQP's control_exchange.
>
> Even if we add artificial support for control_exchange to the ZeroMQ driver
> (which is possible), this won't do Ceilometer any good if people deploy
> ZeroMQ on different ports for different projects. Then, you'll need to add
> a port= kwarg to cast/call/notify, in addition to the control_exchange.  In
> fact, it seems likely that people will want to deploy ZeroMQ on different
> ports for different projects, and we might want to do this by default, so
> it *will* be a problem.
>
> Perhaps the best solution here is to bake in a numeric representation for
> each control_exchange? We'd need to manage these for each core/incubated
> project to prevent overlap. We already do this for the control_exchange,
> although as a string there is little cost to doing so. A bit more effort
> would be needed for tracking port assignments.

This totally makes sense to me. As you point out, my current patch leaks
the control exchange concept to the RPC API and this is not a good idea
at all. I know understand that better, thanks to ZMQ. :-)

I'm thinking out loud: isn't there a way to build a simple ZMQ based
service based, running on a predefined and well known port, on that
would allow one to ask for the TCP port of a given equivalent of control
exchange? A sort of DNS mapping control exchange (we need to find a
generic term for that rather than using AMQP's one) and TCP port?
Or we could also base such a mechanism on DNS itself actually.
Or does this sound over-engineered?

-- 
Julien Danjou
;; Free Software hacker ; freelance consultant
;; http://julien.danjou.info
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 835 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20130424/c24fb8e6/attachment.pgp>