<p dir="ltr">Sending aside sending, Ceilometer is already doing consumption cross-project, receiving notifications from multiple control_exchanges (at least where amqp is concerned).</p>
<div class="gmail_quote">On Apr 24, 2013 9:58 AM, "Russell Bryant" <<a href="mailto:rbryant@redhat.com">rbryant@redhat.com</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On 04/24/2013 09:47 AM, Eric Windisch wrote:<br>
> Discussing in regard to changing the ZeroMQ ipc directory,<br>
> and "allow to cast to other any control exchange"<br>
> <a href="https://review.openstack.org/27351" target="_blank">https://review.openstack.org/27351</a><br>
> <a href="https://review.openstack.org/27346" target="_blank">https://review.openstack.org/27346</a><br>
><br>
> Basically, the fact that one can deploy each project on a different port<br>
> number with ZeroMQ is as close an equivalent (and best practice) as one<br>
> may get to AMQP's control_exchange.<br>
><br>
> Even if we add artificial support for control_exchange to the ZeroMQ<br>
> driver (which is possible), this won't do Ceilometer any good if people<br>
> deploy ZeroMQ on different ports for different projects. Then, you'll<br>
> need to add a port= kwarg to cast/call/notify, in addition to the<br>
> control_exchange.  In fact, it seems likely that people will want to<br>
> deploy ZeroMQ on different ports for different projects, and we might<br>
> want to do this by default, so it *will* be a problem.<br>
><br>
> Perhaps the best solution here is to bake in a numeric representation<br>
> for each control_exchange? We'd need to manage these for each<br>
> core/incubated project to prevent overlap. We already do this for the<br>
> control_exchange, although as a string there is little cost to doing so.<br>
> A bit more effort would be needed for tracking port assignments.<br>
<br>
Implementation details aside ... I'm actually curious why this is needed<br>
in the first place.  What's the use case driving the need for<br>
cross-project rpc calls?  This has been something we've avoided thus<br>
far.  rpc has been private to a given project.<br>
<br>
--<br>
Russell Bryant<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>
</blockquote></div>