Open Stack

On Friday, April 26, 2013 at 04:34 AM, Julien Danjou wrote:

> On Fri, Apr 26 2013, Doug Hellmann wrote:
> 
> > After thinking about this a little more I realized that this doesn't solve
> > the problem of allowing one service to talk to another on a separate
> > "exchange." If that's still something we want to do, we need another
> > argument passed to the ConnectionFactory to represent that exchange
> > explicitly (I know we need another name, but until we come up with one I'll
> > stick with "exchange"). The default can come from the config, but callers
> > like ceilometer need a way to specify an alternative value.
> > 
> > Do we care if the exchange for a service is not on the same host? Do we
> > need to allow users to provide different host/port settings for every
> > exchange?
> 
> 
> 
> Yes, that's why I thought we would include the control exchange as part
> of a connection URL. That would be an abstraction detail for AMQP, where
> url would be something like amqp://localhost:3456/mycontrolexchange.
> 
> For example, in my envisioned Ceilometer case we would just have to specify the
> ceilometer URL as amqp://host:port/ceilometer to be able to use
> rpc.call().
> 
> For our current notification consuming, we sould use an URL for each
> notification listener for each project: amqp://host:port/nova,
> amqp://host:port/glance, etc.
> 
> I'm pretty confident we can map this URL scheme to ZMQ (and its
> matchmaker) and includes all its components in the Connection as
> discriminating.

See again, I'm not sure the MatchMaker is ZeroMQ specific.

1. We're uncertain to what extent the matchmaker may or may not be necessary for message encryption.
2. Our projects need/want a common service registry / health solution. Some projects use the database, Nova now uses ServiceGroup. Both of these are linked to topics and, by extension, the control exchange. The matchmaker may prove to fill, at least partially, this role (my argument is that we should use one solution, not multiple -- whether that is the matchmaker, an improved ServiceGroup codebase, or something new)


Regards,
Eric Windisch