Open Stack

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.

Cheers,
Mark.