Open Stack

> 
> 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 also wondering what Ceilometer's support for multiple AMQP servers should be?  Each control exchange could be comfortably deployed on a separate RabbitMQ/Qpid server without breaking anything, at least anything except Ceilometer.

Perhaps the answer to both of these is to register the control_exchanges in Keystone and retrieve the port numbers for ZeroMQ and the broker addresses for RabbitMQ/Qpid? (Thinking out loud: Perhaps either could be optionally retrieved from DNS SRV records?)

> 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?



This is what SRV records are generally for.  However, requiring DNS isn't very turn-key, with is a bit bothersome. As an option, yes, but as a requirement? I'm a bit hesitant to accept anything that makes things difficult for deployers.

Regards,
Eric Windisch