<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Mon, Apr 29, 2013 at 6:47 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 Wed, 2013-04-24 at 10:42 -0400, Russell Bryant wrote:<br>
> On 04/24/2013 10:35 AM, Julien Danjou wrote:<br>
> > On Wed, Apr 24 2013, Russell Bryant wrote:<br>
> ><br>
> >> On 04/24/2013 10:10 AM, Eric Windisch wrote:<br>
> >>> Sending aside sending, Ceilometer is already doing consumption<br>
> >>> cross-project, receiving notifications from multiple<br>
> >>> control_exchanges (at least where amqp is concerned).<br>
> >><br>
> >> Yes, I'm aware that it's consuming notifications from multiple<br>
> >> projects. The patch in question is about enabling *sending* cross<br>
> >> project. That's what I'm curious about.<br>
> ><br>
> > The use case here is to send metrics to the Ceilometer collector<br>
> > directly from other projects using openstack.common.rpc. To do<br>
> > that, you have to send a message… on another control exchange.<br>
> ><br>
> > As Eric points out, this is typically the same use case we already<br>
> > have, just put in the opposite way: not having the Ceilometer<br>
> > collector joining a bunch of other control exchange (that it may<br>
> > not know about in advance), but having each project send its meters<br>
> > to the right place directly (Ceilometer's control exchange).<br>
><br>
> That seems like a step backwards to me. Right now we have a nice<br>
> generic notification mechanism that can be consumed by ceilometer or<br>
> something else. This would be a move toward coupling all projects<br>
> with ceilometer specifically. Is there something problematic with<br>
> consuming notifications as they are today?<br>
<br>
</div>Yeah, this is an interesting subject. I'm seeing a few different points:<br>
<br>
* RPCs should be for intra project communication<br>
<br>
* Notifications should be used for where you want to make event<br>
notifications available for third parties<br>
<br>
* Just because the RPC notification driver needs to be able to do<br>
something, doesn't mean we also allow other users of the RPC API to<br>
do the same<br>
<br>
* A ceilometer notifications driver is part of the ceilometer project,<br>
so it sending RPCs back to ceilometer-collector is fine<br>
<br>
* There are probably reasonable use cases (like a ceilometer<br>
notifications plugin used by nova, but also cells) for a service to<br>
connect to another broker and/or use a different exchange. Even<br>
without those use cases, though, I think it would be lame for the<br>
API to only allow such things to be specified through global<br>
configuration ... global configuration should be a convenience<br>
default only.<br></blockquote><div><br></div><div style>Agreed. I would prefer it if we could establish an API that didn't use the global configuration object at all.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
However, I'd really like to understand this ceilometer use case better.<br>
See:<br>
<br>
<a href="https://wiki.openstack.org/wiki/Oslo/Messaging#Ceilometer_Metering_Messages" target="_blank">https://wiki.openstack.org/wiki/Oslo/Messaging#Ceilometer_Metering_Messages</a><br>
<br>
Ceilometer is sending record_metering_data casts on the 'metering'<br>
topic. The ceilometer-collector service consumes these, but it uses<br>
create_worker() so that it doesn't use the default queue to receive<br>
them. It's like we're supporting the existence of third party consumers<br>
of these messages which would be peers with ceilometer-collector. Maybe<br>
ceilometer-collector consuming them is intended to be optional?<br></blockquote><div><br></div><div style>Yes, we originally designed ceilometer so that someone could tie into it at any point for integrating with their existing system. I don't know how practical that is in reality, but at the time we were very focused on flexibility.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
I'm mostly curious why 'record_metering_data' isn't a notification if we<br>
want to support third party consumers of it.<br></blockquote><div><br></div><div style>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.</div>
<div style><br></div><div style>Doug</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Cheers,<br>
Mark.<br>
<div class="HOEnZb"><div class="h5"><br>
<br>
_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</div></div></blockquote></div><br></div></div>