<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Mon, Apr 29, 2013 at 10:23 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 09:39 -0400, Doug Hellmann wrote:<br>
><br>
><br>
><br>
> On Mon, Apr 29, 2013 at 7:00 AM, Mark McLoughlin <<a href="mailto:markmc@redhat.com">markmc@redhat.com</a>> wrote:<br>
> 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>
><br>
> 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>
><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>
><br>
> Yes.<br>
><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>
><br>
> s/direct a message to/invoke a method on/<br>
><br>
><br>
> RPC and notification aren't the only usage patterns for messaging. If<br>
> we're going to design a general purpose library, we should not limit<br>
> ourselves to RPC semantics. RPC can be built on top of messaging, but<br>
> it has been painful to try to make it work the other way around.<br>
<br>
</div>I don't think the goal is to design a general purpose library, it's to<br>
clean up the APIs we already have to support our current usage patterns.<br>
The library can grow new APIs to support new usage patterns over time.<br>
<br>
I really don't want to design generic APIs in a vacuum when we have the<br>
much more pressing concern of our current usage patterns. I also don't<br>
want to unnecessarily restrict what messaging systems could be used to<br>
support our current patterns.<br></blockquote><div><br></div><div style>You've already, mostly, separated the transport stuff from the RPC semantics. I think that's all I was asking for, but I want the way we describe it to not say "invoke a method on" but just stick with message delivery. The dispatcher for method invocation is one server-side detail.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im"><br>
> But, yes.<br>
><br>
> > 3. An application must be able to direct a message to a pool of peers<br>
> > (i.e., cast()).<br>
><br>
><br>
> ... and for it to be delivered to one of those peers, yes.<br>
><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>
><br>
> 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>
><br>
><br>
> Something has to know how to map the target to the configuration. What<br>
> does that, and how much does that code know about the transport?<br>
<br>
</div>Ok, on the client side:<br>
<br>
<a href="https://wiki.openstack.org/wiki/Oslo/Messaging#Client_Side_API" target="_blank">https://wiki.openstack.org/wiki/Oslo/Messaging#Client_Side_API</a><br>
<br>
for the simple case, you'd have something like:<br>
<br>
rpc_driver = rpc.get_transport_driver()<br>
<br>
base_rpcapi = BaseAPIClient(rpc_driver)<br>
<br>
base_rpcapi.ping(context, 'foo')<br>
<br>
for the more complex case, you'd have:<br>
<br>
class MeteringAPIClient(rpc.RPCClient):<br>
<br>
target = rpc.Target(exchange='ceilometer',<br>
topic='metering',<br>
version='1.0')<br>
<br>
def __init__(self, driver):<br>
# FIXME: need some way to override with exchange from URL<br></blockquote><div><br></div><div style>Ceilometer knows which exchanges to listen on based on its plugins and configuration (we know to look for the glance notification config option when the glance-related plugins are activated, for example).</div>
<div style><br></div><div style>Cells will know because they will have some configuration setting(s) per cell they want to talk to in the database.</div><div style><br></div><div style>Are those the only cases we have now? Are they the only cases we anticipate?</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
---<br>
<br>
rpc_driver = rpc.get_transport_driver(url='kombu://broker//ceilometer')<br>
<br>
metering_rpcapi = MeteringAPIClient(rpc_driver)<br>
metering_rpc_api.record_metering_data(...)<br>
<br>
The annoying bit here is the application code should know what the<br>
default exchange is, but there is a use case for it to be overridden by<br>
configuration.<br></blockquote><div><br></div><div style>If the application gets the URL to pass to get_transport_driver() from a config file or the database, does it even need to know there is such a thing as an "exchange" any more?</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc 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>
><br>
> 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>
><br>
><br>
> Probably.<br>
<br>
</div>Hmm, ok :)<br></blockquote><div><br></div><div style>See the other message where I explained that in a little more detail. :-)</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>
<br>
<br>
</blockquote></div><br></div></div>