On Fri, 2015-03-27 at 17:01 +0000, Tim Bell wrote: > From the stats > (http://superuser.openstack.org/articles/openstack-user-survey-insights-november-2014), > > > - 43% of production clouds use OVS (the default for Neutron) > > - 30% of production clouds are Nova network based > > - 15% of production clouds use linux bridge > > There is therefore a significant share of the OpenStack production > user community who are interested in a simple provider network linux > bridge based solution. > > I think it is important to make an attractive cloud solution where > deployers can look at the balance of function and their skills and > choose the appropriate combinations. > > Whether a simple network model should be the default is a different > question to should there be a simple option. Personally, one of the > most regular complaints I get is the steep learning curve for a new > deployment. If we could make it so that people can do it as a series > of steps (by making an path to add OVS) rather than a large leap, I > think that would be attractive.
To be honest, there's a technology gap between the LinuxBridge and OVS that cannot be filled. We've found, since we sell technology to hosting companies, that we got an immediate back reaction when we tried to switch from a LinuxBridge to OVS in our Cloud Server product. The specific problem is that lots of hosting providers have heavily scripted iptables and traffic control rules on the host side (i.e. on the bridge) for controlling client networks which simply cannot be replicated in OVS. Telling the customers to rewrite everything in OpenFlow causes incredulity and threats to pull the product. No currently existing or planned technology is there to fill this gap (the closest was google's plan to migrate iptables rules to openflow, which died). Our net takeaway is that we have to provide both options for the foreseeable future (scripting works to convert some use cases, but by no means all ... and in our case not even a majority). So the point of this for OpenStack is seeing this as a choice between LinuxBridge and OVS is going to set up a false dichotomy. Realistically the future network technology has to support both, at least until the trailing edge becomes more comfortable with SDN. Moving neutron to ML2 instead of L2 helps isolate neutron from the bridge technology, but it doesn't do anything to help the customer who is currently poking at L2 to implement specific policies because they have to care what the bridge technology is. Telling the customer not to poke the bridge isn't an option because they see the L2 plane as their primary interface to diagnose and fix network issues ... which is why they care about the bridge technology. James __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
