[openstack-dev] [OSLO][RPC] AMQP / ZeroMQ control_exchange vs port numbers
doug.hellmann at dreamhost.com
Mon Apr 29 13:46:14 UTC 2013
On Mon, Apr 29, 2013 at 9:36 AM, Mark McLoughlin <markmc at redhat.com> wrote:
> On Mon, 2013-04-29 at 09:19 -0400, Doug Hellmann wrote:
> > On Mon, Apr 29, 2013 at 6:36 AM, Mark McLoughlin <markmc at redhat.com>
> > 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
> > > > > 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
> > >
> > >
> > > 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
> > way of configuring the default transport that a service uses,
> but also
> > support URLs for configuring alternate transports e.g.
> > > 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
> > 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?)?
> Yeah, AFAIK. The cell name to transport configuration goes into the
OK, that makes that a bit simpler, then.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the OpenStack-dev