<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Mon, Apr 29, 2013 at 9:36 AM, Mark McLoughlin <span dir="ltr"><<a href="mailto:markmc@redhat.com" target="_blank">markmc@redhat.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">On Mon, 2013-04-29 at 09:19 -0400, Doug Hellmann wrote:<br>
><br>
><br>
><br>
> On Mon, Apr 29, 2013 at 6:36 AM, Mark McLoughlin <<a href="mailto:markmc@redhat.com">markmc@redhat.com</a>> wrote:<br>
>         On Fri, 2013-04-26 at 07:19 -0400, Doug Hellmann wrote:<br>
>         > On Friday, April 26, 2013, Julien Danjou wrote:<br>
>         ><br>
>         > > On Fri, Apr 26 2013, Doug Hellmann wrote:<br>
>         > ><br>
>         > > > After thinking about this a little more I realized that this doesn't<br>
>         > > solve<br>
>         > > > the problem of allowing one service to talk to another on a separate<br>
>         > > > "exchange." If that's still something we want to do, we need another<br>
>         > > > argument passed to the ConnectionFactory to represent that exchange<br>
>         > > > explicitly (I know we need another name, but until we come up with one<br>
>         > > I'll<br>
>         > > > stick with "exchange"). The default can come from the config, but callers<br>
>         > > > like ceilometer need a way to specify an alternative value.<br>
>         > > ><br>
>         > > > Do we care if the exchange for a service is not on the same host? Do we<br>
>         > > > need to allow users to provide different host/port settings for every<br>
>         > > > exchange?<br>
>         > ><br>
>         > > Yes, that's why I thought we would include the control exchange as part<br>
>         > > of a connection URL. That would be an abstraction detail for AMQP, where<br>
>         > > url would be something like amqp://localhost:3456/mycontrolexchange.<br>
>         ><br>
>         ><br>
>         > I definitely like the idea of using a URL instead of the multiple params we<br>
>         > have now, but we will need a way to migrate or otherwise support old<br>
>         > configs.<br>
><br>
><br>
>         I think we can support the current config format as the more convenient<br>
>         way of configuring the default transport that a service uses, but also<br>
>         support URLs for configuring alternate transports e.g.<br>
><br>
>           <a href="https://wiki.openstack.org/wiki/Oslo/Messaging#Transport_Driver_API" target="_blank">https://wiki.openstack.org/wiki/Oslo/Messaging#Transport_Driver_API</a><br>
><br>
>         > The real challenge, in my mind, is how to know which URL to use for a given<br>
>         > connection. If we have several, what values are part of the lookup key?<br>
><br>
><br>
>         Well, if this is ceilometer wanting to listen for nova notifications,<br>
>         then you just have a config option in ceilometer like<br>
><br>
>           nova_notifications_url = kombu://broker//nova/notifications<br>
><br>
><br>
> That's basically what we have for ceilometer now, although we only specify the exchange.<br>
><br>
><br>
> I'm not sure that works so well for cells, though. Does a parent cell<br>
> have a configuration setting for each of its children? How does it<br>
> address the children (do cells have names or unique ids or<br>
> something?)?<br>
<br>
</div></div>Yeah, AFAIK. The cell name to transport configuration goes into the<br>
database.<br></blockquote><div><br></div><div style>OK, that makes that a bit simpler, then.</div><div style><br></div><div style>Doug</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<br>
Cheers,<br>
Mark.<br>
<br>
<br>
</blockquote></div><br></div></div>