[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