Open Stack

>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.

BTW, CERN is on nova network with 3,200 hypervisors across 2 sites and we're interested to move to Neutron to stay mainstream. The CERN network is set up as a series of IP services which correspond to broadcast domains. A typical IP service is around 200-500 servers with a set of top of the rack switches and one or two router uplinks. An IP address is limited to an IP service. We then layer a secondary set of IP networks on the hypervisors on the access switches which are allocated to VMs. We change router and switch vendor on average every 5 years as part of public procurement and therefore generic solutions are required. Full details of the CERN network can be found at http://indico.cern.ch/event/327056/contribution/0/material/slides/0.pdf.

Tim

From: Fox, Kevin M [mailto:Kevin.Fox at pnnl.gov]
Sent: 27 March 2015 17:36
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Nova][Neutron] Status of the nova-network to Neutron migration work

No, no. Most OpenStack deployments are neutron based with ovs because its the default these days.

There are all sorts of warnings to folks for years saying if you start with nova-network, there will be pain for you later. Hopefully, that has scared away most new folks from doing it. Most of the existing folks are there because they started before Neutron was up to speed. Thats a different problem.

So I would expect the number of folks needing to go from nova-network to neutron to be a small number of clouds, not a big number. Changing the defaults now to favor that small minority of clouds, seems like an odd choice.

Really, I don't think finding the right solution to migrate those still using nova-network to neutron has anything to do with what the default out of the box experience for new clouds should be...

Having linuxbridge be the default for folks moving from nova-network to neutron might make much more sense then saying everyone should by default get linuxbridge.

Thanks,
Kevin
________________________________
From: Dean Troyer [dtroyer at gmail.com]
Sent: Friday, March 27, 2015 9:06 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Nova][Neutron] Status of the nova-network to Neutron migration work
On Fri, Mar 27, 2015 at 10:48 AM, Assaf Muller <amuller at redhat.com<mailto:amuller at redhat.com>> wrote:
Looking at the latest user survey, OVS looks to be 3 times as popular as
Linux bridge for production deployments. Having LB as the default seems
like an odd choice. You also wouldn't want to change the default before
LB is tested at the gate.

Simple things need to be simple to accomplish, and defaults MUST be simple to use.

LB's support requirements are very simple compared to OVS.  This is an achievable first step away from nova-net and once conquered the second step becomes less overwhelming.  Look at the success of swallowing the entire elephant at once that we've seen in the last $TOO_MANY years.

dt

--

Dean Troyer
dtroyer at gmail.com<mailto:dtroyer at gmail.com>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150327/8798e064/attachment.html>