[openstack-dev] [OSLO][RPC] AMQP / ZeroMQ control_exchange vs port numbers
doug.hellmann at dreamhost.com
Mon Apr 29 16:04:02 UTC 2013
On Mon, Apr 29, 2013 at 11:52 AM, Mark McLoughlin <markmc at redhat.com> wrote:
> On Mon, 2013-04-29 at 11:04 -0400, Doug Hellmann wrote:
> > On Mon, Apr 29, 2013 at 10:29 AM, Mark McLoughlin <markmc at redhat.com>
> > On Mon, 2013-04-29 at 09:45 -0400, Eric Windisch wrote:
> > > >
> > > > It was, originally, but create_worker() uses the RPC
> dispatcher so we had to change. Now that we have join_consumer_pool() in
> the public API, we could change back.
> > > >
> > >
> > >
> > > Is create_worker not used in Ceilometer anymore? This was
> added for
> > > Ceilometer's benefit. If it isn't used, we might want to
> deprecate it.
> > It is used to listen on the 'metering' topic ... but I'm not
> > sure why.
> > # Set ourselves up as a separate worker for the metering
> > # since the default for service is to use
> > self.conn.create_worker(
> > cfg.CONF.metering_topic,
> > rpc_dispatcher.RpcDispatcher([self]),
> > 'ceilometer.collector.' + cfg.CONF.metering_topic,
> > )
> > The best guess I can come up for this is that we want to use a
> > non-default worker pool so that third party listeners can use the
> > default worker pool.
> > If I had written join_consumer_pool() before create_worker() I would
> > never have needed create_worker(). I'd like to wait for the new rpc
> > API to come out before changing ceilometer, but I think we can assume
> > create_worker() could go away.
> I still don't understand what was wrong with create_consumer() for this
> use case, though. Why not just use the default worker pool?
> Is it to support 3rd party listeners? If so, they could just add another
> pool without us the default pool interfering with them.
I frankly don't remember. It's possible that I thought we might want some
other RPC mechanism where we *wouldn't* want the third party listeners
getting involved, so I was saving the 'ceilometer' worker pool name for
something that just never materialized. It's also possible that I just
thought cast() was point-to-point and we would have to know the identity of
the recipient in the sender, so I didn't think create_consumer() would work
Suffice to say, I am reasonably certain that notifications and
join_consumer_pool() will take care of ceilometer's current use cases, so
we could move to the equivalent of that in the new RPC API and get rid of
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the OpenStack-dev