<div dir="ltr"><div><div><div>I had always wanted this to happen. It is really frustrating when nova throws wierd python exceptions and difficult to comprehend log messages. <br><br></div>If the developers do agree to clean up the interface I would suggest they make use of some well knows protocol (mpls/rsvp) to do this, instead of relying on custom south-bound api calls. <br><br></div>regards,<br></div><div>Ageeleshwar K<br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Jan 22, 2015 at 9:39 PM, Sean Dague <span dir="ltr"><<a href="mailto:sean@dague.net" target="_blank">sean@dague.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">On 01/22/2015 10:28 AM, Salvatore Orlando wrote:<br>
> Hi,<br>
><br>
> We have attempted several times to start a conversation around the<br>
> interface between nova and neutron and its problems, starting with the<br>
> fact that it's chatter than two Italians arguing about football (*).<br>
> Indeed the first attempt at fixing these problems goes back to the Fall<br>
> 2012 summit [1]. While we probably don't want to introduce yet another<br>
> service to this aim, it might be worth giving another shot at having<br>
> these two project communicate in a decent way. I know that other<br>
> developers are interested in this and are probably even already actively<br>
> working on this topic.<br>
><br>
> In my opinion it might not be such a bad idea to start this conversation<br>
> at the upcoming nova meetup, if there will be enough interest from the<br>
> participants. I have started the etherpad [2] for discussing issues of<br>
> the current implementation, goals, architecture, and design.<br>
><br>
> As for timelines, it is very likely already too late for shipping this<br>
> in Kilo, but we're probably still on time for completing this work by<br>
> the "L" release.<br>
><br>
> Salvatore<br>
><br>
> (*) being Italian I am entitled to make jokes about Italians without<br>
> offending anyone, I hope.<br>
><br>
> [1] <a href="https://etherpad.openstack.org/p/grizzly-newtonian" target="_blank">https://etherpad.openstack.org/p/grizzly-newtonian</a><br>
> [2] <a href="https://etherpad.openstack.org/p/nova-neutron-interface-rework" target="_blank">https://etherpad.openstack.org/p/nova-neutron-interface-rework</a><br>
<br>
</div></div>Interesting stuff. I conceptually like the idea of nova-compute doing<br>
the leg work for sub resources (like the network) as it feels like error<br>
handling is simpler given it's closeness to the actual VMs that are<br>
running.<br>
<br>
I also like the idea of considering the RPC interface. What kind of<br>
stability / versioning exists on the Neutron RPC interface?<br>
<span class="HOEnZb"><font color="#888888"><br>
        -Sean<br>
<br>
--<br>
Sean Dague<br>
<a href="http://dague.net" target="_blank">http://dague.net</a><br>
<br>
</font></span><br>__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</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>
<br></blockquote></div><br></div>