<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Mon, Apr 29, 2013 at 11:52 AM, Mark McLoughlin <span dir="ltr"><<a href="mailto:markmc@redhat.com" target="_blank">markmc@redhat.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">On Mon, 2013-04-29 at 11:04 -0400, Doug Hellmann wrote:<br>
><br>
><br>
><br>
> On Mon, Apr 29, 2013 at 10:29 AM, Mark McLoughlin <<a href="mailto:markmc@redhat.com">markmc@redhat.com</a>> wrote:<br>
>         On Mon, 2013-04-29 at 09:45 -0400, Eric Windisch wrote:<br>
>         > ><br>
>         > > 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.<br>
>         > ><br>
>         ><br>
>         ><br>
>         > Is create_worker not used in Ceilometer anymore? This was added for<br>
>         > Ceilometer's benefit. If it isn't used, we might want to deprecate it.<br>
><br>
><br>
>         It is used to listen on the 'metering' topic ... but I'm not entirely<br>
>         sure why.<br>
><br>
>                 # Set ourselves up as a separate worker for the metering data,<br>
>                 # since the default for service is to use create_consumer().<br>
>                 self.conn.create_worker(<br>
>                     cfg.CONF.metering_topic,<br>
>                     rpc_dispatcher.RpcDispatcher([self]),<br>
>                     'ceilometer.collector.' + cfg.CONF.metering_topic,<br>
>                 )<br>
><br>
>         The best guess I can come up for this is that we want to use a<br>
>         non-default worker pool so that third party listeners can use the<br>
>         default worker pool.<br>
><br>
><br>
> If I had written join_consumer_pool() before create_worker() I would<br>
> never have needed create_worker(). I'd like to wait for the new rpc<br>
> API to come out before changing ceilometer, but I think we can assume<br>
> create_worker() could go away.<br>
<br>
</div>I still don't understand what was wrong with create_consumer() for this<br>
use case, though. Why not just use the default worker pool? </blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Is it to support 3rd party listeners? If so, they could just add another<br>
pool without us the default pool interfering with them.<br></blockquote><div><br></div><div style>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.</div>
<div style><br></div><div style>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().</div>
<div style><br></div><div style>Doug</div><div style><br></div></div></div></div>