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

Doug Hellmann doug.hellmann at dreamhost.com
Mon Apr 29 14:45:31 UTC 2013


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

> On Mon, 2013-04-29 at 09:28 -0400, Doug Hellmann wrote:
> >
> >
> >
> > On Mon, Apr 29, 2013 at 6:47 AM, Mark McLoughlin <markmc at redhat.com>
> wrote:
>
> >
> >          * There are probably reasonable use cases (like a ceilometer
> >            notifications plugin used by nova, but also cells) for a
> service to
> >            connect to another broker and/or use a different exchange.
> Even
> >            without those use cases, though, I think it would be lame for
> the
> >            API to only allow such things to be specified through global
> >            configuration ... global configuration should be a convenience
> >            default only.
> >
> >
> > Agreed. I would prefer it if we could establish an API that didn't use
> > the global configuration object at all.
>
> I guess I'm thinking that this is the only place it's used:
>
>     def get_transport_driver(url=None, conf=None):
>         conf = conf or cfg.CONF
>
> i.e. the entry point into the library is to construct a transport
> driver. If that has optional support for using the global object, I
> don't think it's a big deal.
>

I'd rather we just have the caller pass it in. Unless we're going to have a
handle to it already?


> When I said "global configuration", though, I actually more meant that
> it would be lame if transport configuration could only come from a cfg
> object - e.g. if ceilometer had to construct a cfg object with the
> configuration required to connect to glance notifications.
>

Yes, we should *definitely* avoid that.

Doug


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


More information about the OpenStack-dev mailing list