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

Doug Hellmann doug.hellmann at dreamhost.com
Mon Apr 29 13:19:26 UTC 2013


On Mon, Apr 29, 2013 at 6:36 AM, Mark McLoughlin <markmc at redhat.com> wrote:

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

That's basically what we have for ceilometer now, although we only specify
the exchange.

I'm not sure that works so well for cells, though. Does a parent cell have
a configuration setting for each of its children? How does it address the
children (do cells have names or unique ids or something?)?

Doug


>
> Cheers,
> Mark.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20130429/a462cb81/attachment.html>


More information about the OpenStack-dev mailing list