<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Mon, Apr 29, 2013 at 7:00 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:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div class="im">On Fri, 2013-04-26 at 15:18 -0400, Doug Hellmann wrote:<br>

<br>
> We've gone around a few times with ideas for having better driver-parity in<br>
> the rpc library, so maybe the best thing to do is start by making sure we<br>
> have all of the requirements lined up. Here's a list of some that I came up<br>
> with based on existing features and my understanding of the shortcomings<br>
> (numbered for reference, but in no particular order):<br>
<br>
</div>Thanks for doing this. We definitely need to be stepping back and<br>
thinking about this at a high level. I've attempted to step a little<br>
further back in my writeup:<br>
<br>
  <a href="https://wiki.openstack.org/wiki/Oslo/Messaging" target="_blank">https://wiki.openstack.org/wiki/Oslo/Messaging</a><br>
<div class="im"><br>
> 1. Application code using RPC connections must not be required to know to<br>
> pass different arguments to establish the connection (i.e., the app<br>
> shouldn't have to care if it is using Rabbit or ZMQ).<br>
<br>
</div>Yes.<br>
<div class="im"><br>
> 2. An application must be able to direct a message to a specific peer<br>
> (i.e., call() with a host specified).<br>
<br>
</div>s/direct a message to/invoke a method on/<br></blockquote><div><br></div><div style>RPC and notification aren't the only usage patterns for messaging. If we're going to design a general purpose library, we should not limit ourselves to RPC semantics. RPC can be built on top of messaging, but it has been painful to try to make it work the other way around.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<br>
But, yes.<br>
<div class="im"><br>
> 3. An application must be able to direct a message to a pool of peers<br>
> (i.e., cast()).<br>
<br>
</div>... and for it to be delivered to one of those peers, yes.<br>
<div class="im"><br>
> 4. An application must be able to direct a message to a specific peer (or<br>
> unknown? or both?) using a different rpc endpoint than the originating<br>
> app's default (i.e., calling into cells).<br>
<br>
</div>I've tried to separate the notion of a transport from the target. The<br>
properties of the target is what's known to the application code, the<br>
properties of the transport are target specific and come from<br>
configuration.<br>
<br>
So, I'd say "an application must be able to invoke a method on a<br>
specific target using a supplied transport configuration".<br></blockquote><div><br></div><div style>Something has to know how to map the target to the configuration. What does that, and how much does that code know about the transport?</div>
<div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div class="im"><br>
> 5. An application must be able to listen for messages without interfering<br>
> with others receiving those same messages (i.e., join_consumer_pool()).<br>
<br>
</div>For notifications, yes - and we should have an API for consuming<br>
notifications.<br>
<br>
But for RPC (i.e. create_worker()), I don't really see it. See here:<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>
Should ceilometer be using notifications instead of record_metering_data()<br></blockquote><div><br></div><div style>Probably.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">

<div class="im"><br>
> 6. An application must be able to listen for messages sent by any peer, and<br>
> any service (i.e., specifying a different "exchange", though we want to<br>
> extend this to include a different broker as well).<br>
<br>
</div>For notifications, yes.<br>
<br>
For RPC, this sounds like a "tap" - i.e. listen in on RPC exchanges<br>
between peers.<br>
<div class="im"><br>
> 7. Any configuration changes must maintain backwards compatibility (i.e.,<br>
> if we move to URLs instead of N different variables, we still have to<br>
> support the old format somehow for some time).<br>
<br>
</div>Yes.<br>
<br>
Thanks,<br>
Mark.<br>
<div class=""><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>