Open Stack

On Mon, 2013-04-29 at 12:04 -0400, Doug Hellmann wrote:
> 
> 
> 
> 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().

Great!

Cheers,
Mark.