<p dir="ltr">It's worth pointing out here that the in-tree OVS solution controls traffic using iptables on regular bridges too. The difference between the two occurs when it comes to how traffic is separated into different networks. </p>
<p dir="ltr">It's also worth noting that DVR requires OVS as well. If nobody is comfortable with OVS then they can't use DVR and they won't have parity with Nova network as far as floating IP resilience and performance is concerned. </p>
<div class="gmail_quote">On Mar 31, 2015 4:56 AM, "James Bottomley" <<a href="mailto:James.Bottomley@hansenpartnership.com">James.Bottomley@hansenpartnership.com</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Fri, 2015-03-27 at 17:01 +0000, Tim Bell wrote:<br>
> From the stats (<a href="http://superuser.openstack.org/articles/openstack-user-survey-insights-november-2014" target="_blank">http://superuser.openstack.org/articles/openstack-user-survey-insights-november-2014</a>),<br>
><br>
><br>
> -        43% of production clouds use OVS (the default for Neutron)<br>
><br>
> -        30% of production clouds are Nova network based<br>
><br>
> -        15% of production clouds use linux bridge<br>
><br>
> There is therefore a significant share of the OpenStack production<br>
> user community who are interested in a simple provider network linux<br>
> bridge based solution.<br>
><br>
> I think it is important to make an attractive cloud solution  where<br>
> deployers can look at the balance of function and their skills and<br>
> choose the appropriate combinations.<br>
><br>
> Whether a simple network model should be the default is a different<br>
> question to should there be a simple option. Personally, one of the<br>
> most regular complaints I get is the steep learning curve for a new<br>
> deployment. If we could make it so that people can do it as a series<br>
> of steps (by making an path to add OVS) rather than a large leap, I<br>
> think that would be attractive.<br>
<br>
To be honest, there's a technology gap between the LinuxBridge and OVS<br>
that cannot be filled.  We've found, since we sell technology to hosting<br>
companies, that we got an immediate back reaction when we tried to<br>
switch from a LinuxBridge to OVS in our Cloud Server product.  The<br>
specific problem is that lots of hosting providers have heavily scripted<br>
iptables and traffic control rules on the host side (i.e. on the bridge)<br>
for controlling client networks which simply cannot be replicated in<br>
OVS.  Telling the customers to rewrite everything in OpenFlow causes<br>
incredulity and threats to pull the product.  No currently existing or<br>
planned technology is there to fill this gap (the closest was google's<br>
plan to migrate iptables rules to openflow, which died).  Our net<br>
takeaway is that we have to provide both options for the foreseeable<br>
future (scripting works to convert some use cases, but by no means<br>
all ... and in our case not even a majority).<br>
<br>
So the point of this for OpenStack is seeing this as a choice between<br>
LinuxBridge and OVS is going to set up a false dichotomy.  Realistically<br>
the future network technology has to support both, at least until the<br>
trailing edge becomes more comfortable with SDN.<br>
<br>
Moving neutron to ML2 instead of L2 helps isolate neutron from the<br>
bridge technology, but it doesn't do anything to help the customer who<br>
is currently poking at L2 to implement specific policies because they<br>
have to care what the bridge technology is.  Telling the customer not to<br>
poke the bridge isn't an option because they see the L2 plane as their<br>
primary interface to diagnose and fix network issues ... which is why<br>
they care about the bridge technology.<br>
<br>
James<br>
<br>
<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>
</blockquote></div>