<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Fri, Apr 26, 2013 at 1:28 PM, Eric Windisch <span dir="ltr"><<a href="mailto:eric@cloudscaling.com" target="_blank">eric@cloudscaling.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"><br>
> Up to this point, projects have interfaced with each other via HTTP<br>
> APIs. It seems much easier to replace a project with an alternate<br>
> implementation using HTTP based interfaces than one that presents the<br>
> equivalent of our home-grown rpc communication. I'm concerned about a<br>
> future where projects become more tightly coupled due to rpc<br>
> communications as opposed to HTTP APIs.<br>
<br>
</div>Except we have certain scale and availability characteristics around RPC that don't apply natively to HTTP and specifically not to our HTTP servers or clients. There is nothing that would prevent us from supporting an HTTP-based "rpc" driver, if the low-level protocol is a problem.<br>

<br>
I think the problems with using and maintaining RPC compatibility across projects is of a greater concern than if there is an API to allow it.<br></blockquote><div><br></div><div style>The plugin Julien is describing won't be cross-project. It will live in the ceilometer team code base, and talk to the ceilometer services. It will run *in* nova, but it won't be a permanent part *of* nova. Any API compatibility issues will be addressed by the ceilometer team.<br>
</div><div style><br></div><div style>We've gone around a few times with ideas for having better driver-parity in the rpc library, so maybe the best thing to do is start by making sure we have all of the requirements lined up. Here's a list of some that I came up with based on existing features and my understanding of the shortcomings (numbered for reference, but in no particular order):</div>
<div style><br></div><div style>1. Application code using RPC connections must not be required to know to pass different arguments to establish the connection (i.e., the app shouldn't have to care if it is using Rabbit or ZMQ).</div>
<div style><br></div><div style>2. An application must be able to direct a message to a specific peer (i.e., call() with a host specified).</div><div style><br></div><div style>3. An application must be able to direct a message to a pool of peers (i.e., cast()).</div>
<div style><br></div><div style>4. An application must be able to direct a message to a specific peer (or unknown? or both?) using a different rpc endpoint than the originating app's default (i.e., calling into cells).</div>
<div style><div><br class="">5. An application must be able to listen for messages without interfering with others receiving those same messages (i.e., join_consumer_pool()).</div><div><br></div><div style>6. An application must be able to listen for messages sent by any peer, and any service (i.e., specifying a different "exchange", though we want to extend this to include a different broker as well).</div>
<div><br></div></div><div style><div>7. Any configuration changes must maintain backwards compatibility (i.e., if we move to URLs instead of N different variables, we still have to support the old format somehow for some time).<br>
</div><div><br></div><div style>Are those accurate? Complete?</div><div style><br></div><div style>Doug</div></div><div><br></div></div></div></div>