<div dir="ltr">And since we've circled back I might add that perhaps we want nova-network to deliver that.<div>Simple, reliable networking leveraging well-established off-the-shelf technologies that satisfies the use cases Jeremy is referring to.</div><div><br></div><div>If regardless of changes in governance pertaining openstack project the consensus is still that nova-network functionalities should be performed by neutron under the same assumptions, then what Kevin is suggesting goes in the right direction, regardless of whether the deployer chooses linux bridge, OVS, or some fancy advanced technology like [1]. However, there's more than that. For instance ask the average user that "just wants connectivity" whether they think creating a router or pointing a floating ip to a port should be part of their workflow. You can figure out the answer by yourself.</div><div><br></div><div>I had a chat with Sean Dague a few day back on IRC [2]. The point seems that when neutron is deployed as a replacement for nova-network it should provide defaults that provide a replacement for nova-network flatdhcp networking mode. For instance this would be a shared network, a single router, and a single external network (the floating IP pool). </div><div><br></div><div>If multi-host is required that single router should be distributed (and perhaps one day neutron will distribute SNAT too). Router distribution with linux bridge might be a problem with the current framework, where we're insisting on supporting nova-network scenario using neutron's control plane constructs which have been conceived for multi-tenancy and self service networking.</div><div><br></div><div>And then there's the API usability perspective. But if we provide default for neutron resources then the problem is probably solved as users will have little to no  interaction with the neutron API. </div><div><br></div><div>Salvatore</div><div><br></div><div><br></div><div>[1] <a href="https://github.com/salv-orlando/hdn">https://github.com/salv-orlando/hdn</a><br><div class="gmail_extra">[2] <a href="http://eavesdrop.openstack.org/irclogs/%23openstack-neutron/%23openstack-neutron.2015-04-15.log">http://eavesdrop.openstack.org/irclogs/%23openstack-neutron/%23openstack-neutron.2015-04-15.log</a> from <span style="color:rgb(0,0,0);white-space:pre-wrap">2015-04-15T13:26:55 </span></div><div class="gmail_extra"><font color="#000000"><span style="white-space:pre-wrap"><br></span></font><div class="gmail_quote">On 17 April 2015 at 17:22, Jeremy Stanley <span dir="ltr"><<a href="mailto:fungi@yuggoth.org" target="_blank">fungi@yuggoth.org</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"><span class="">On 2015-04-16 21:17:03 -0700 (-0700), Kevin Benton wrote:<br>
> What do you disagree with? I was pointing out that using Linux<br>
> bridge will not reduce the complexity of the model of self-service<br>
> networking, which is what the quote was complaining about.<br>
<br>
</span>On the contrary, if you reread the message to which you were<br>
previously replying, it's was about the unnecessary complexity of<br>
OVS (and Neutron in general) for deployments which explicitly<br>
_don't_ need and can never take advantage of self-service<br>
networking. The implication being that Neutron needs a "just connect<br>
everything to a simple flat network on a bridge I can easily debug"<br>
mode which hides or eliminates those complexities instead.<br>
<div class=""><div class="h5">--<br>
Jeremy Stanley<br>
<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>
</div></div></blockquote></div><br></div></div></div>