Open Stack

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.

Cheers,
Mark.