[openstack-dev] [OSLO][RPC] AMQP / ZeroMQ control_exchange vs port numbers

Mark McLoughlin markmc at redhat.com
Mon Apr 29 10:36:08 UTC 2013


On Fri, 2013-04-26 at 07:19 -0400, Doug Hellmann wrote:
> On Friday, April 26, 2013, 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.
> 
> 
> I definitely like the idea of using a URL instead of the multiple params we
> have now, but we will need a way to migrate or otherwise support old
> configs.

I think we can support the current config format as the more convenient
way of configuring the default transport that a service uses, but also
support URLs for configuring alternate transports e.g.

  https://wiki.openstack.org/wiki/Oslo/Messaging#Transport_Driver_API

> The real challenge, in my mind, is how to know which URL to use for a given
> connection. If we have several, what values are part of the lookup key?

Well, if this is ceilometer wanting to listen for nova notifications,
then you just have a config option in ceilometer like

  nova_notifications_url = kombu://broker//nova/notifications

Cheers,
Mark.




More information about the OpenStack-dev mailing list