<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On 27 August 2014 13:34, Julian Edwards <span dir="ltr"><<a href="mailto:julian.edwards@canonical.com" target="_blank">julian.edwards@canonical.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><br>
> For now the primary goal with RPC is to remove Celery and RabbitMQ<br>
> from the stack, and I think we'd be better served by adding a single<br>
> new RPC call to the region, GetSecrets (say), so we can continue to<br>
> use the <span>API</span> from clusters.<br>
<br>
</div>Urgh.....</blockquote></div><br><div class="gmail_extra">That said, ISTM kind of odd to be reimplementing a lot of stuff to not use the API when we have a perfectly functioning API _which we're not going to remove_.</div>

<div class="gmail_extra"><br>
</div><div class="gmail_extra">Consider, in provisioningserver.dhcp.detect we have `determine_cluster_interfaces()`, which just calls api/1.0/nodegroups/<nodegroup_uuid>/interfaces/list to get the interfaces on the cluster. Do we really want to add YARPC just for the sake of that? We're going to potentially find more and more of these as we go, so we should either declare API off-limits altogether for cluster->region comms or we shouldn't spend time reimplementing APIs that don't need to be reimplemented. Word from God now would be beneficial to avoid flapping later.</div>


</div></div>