Open Stack

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>
> wrote:
> >         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
> entirely
> >         sure why.
> >
> >                 # Set ourselves up as a separate worker for the metering
> data,
> >                 # since the default for service is to use
> create_consumer().
> >                 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
at all.

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
create_worker().

Doug
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20130429/0afd2a6d/attachment.html>