Open Stack

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