Open Stack

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>
> 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?)?
>
> Yeah, AFAIK. The cell name to transport configuration goes into the
> database.
>

OK, that makes that a bit simpler, then.

Doug


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