<div dir="ltr"><div><span style="font-family:arial,sans-serif">></span><span style="font-size:13.333333969116211px;font-family:arial,sans-serif">In all seriousness, folks, I'm bringing up points about the proposed API because I see the current mess of Neutron integration with Nova, I see that nova-network has been "undeprecated" due to continuing lack of parity and HA concerns in Neutron, and I want things to be better, not worse.</span><br>

</div><div><span style="font-family:arial,sans-serif"><br></span></div><div><span style="font-family:arial,sans-serif">Again, I haven't seen any evidence that ongoing development of this new API is preventing any of the parity work from happening. Nobody is advocating that the parity work be delayed because of this. We are all aware of the threats the TC has put forth with regard to demoting Neutron to incubation unless the parity demands are met. If you want ongoing development to stop, this should be a clear requirement and it should be evenly applied to all work (LBaaS separation, ML2 enhancements, any third party drivers, etc).</span></div>

<div><br></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, Aug 6, 2014 at 3:10 PM, Jay Pipes <span dir="ltr"><<a href="mailto:jaypipes@gmail.com" target="_blank">jaypipes@gmail.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="">On 08/06/2014 04:51 PM, Pedro Marques wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Neutron allows vendors to speak to proprietary device APIs, it was<br>
designed to do so, AFAIK. It is also possibly to "entirely swap out<br>
all of the Neutron core"... the proponents of the group based policy<br>
didn't have to go through so much trouble if that was their intent.<br>
As far as i know most plugins talk to a proprietary API.<br>
<br>
I happen to disagree technically with a couple of choices made by<br>
this proposal; but the blueprint was approved. Which means that i<br>
lost the argument, or didn't raise it on time, or didn't argue<br>
convincingly... regardless of the reason, the time to argue about the<br>
goal has passed. The decision of the community was to approve the<br>
spec and that decision should be respected.<br>
</blockquote>
<br></div>
Sure, no problem. I'll just go back to Nova and wait around to help clean up the mess.<br>
<br>
In all seriousness, folks, I'm bringing up points about the proposed API because I see the current mess of Neutron integration with Nova, I see that nova-network has been "undeprecated" due to continuing lack of parity and HA concerns in Neutron, and I want things to be better, not worse.<br>


<br>
Neutron contributors need to recognize that Nova is the pre-eminent consumer of Neutron interfaces, and until those interfaces are stable, consistent regardless of underlying hardware or driver choices, and generally preferable for Nova to recommend as its default network driver, then the Neutron project is sitting as an island unto itself.<br>


<br>
The fact that not enough Nova developers (including yours truly) are paying attention to what is going on in Neutron spec-land and roadmap is a serious problem we should deal with directly (cross-project spec meetings, better documentation and communication, shared bug triaging and verification meetings, etc). Otherwise, these kinds of conversations are likely to continue.<br>


<br>
Best,<br>
-jay<div class="HOEnZb"><div class="h5"><br>
<br>
______________________________<u></u>_________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.<u></u>org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/<u></u>cgi-bin/mailman/listinfo/<u></u>openstack-dev</a><br>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br><div>Kevin Benton</div>
</div>