<div dir="ltr"><div>Are folks using Quantum / Neutron in production? If so:</div><div><br></div><div>a) What is your configuration? What drivers are you using? At what scale?</div><div><br></div><div>b) Are you happy with it? What problems do you encounter?</div>

<div><br></div>I am deploying a Grizzly build after successfully running Diablo and Essex in production for several years. The production builds are medium sized (~600 machines). I expect to run into a few problems when deploying new software. But the things I've seen with quantum do not inspire confidence:<div>

<br></div><div>- No support for clean network teardown: once service ports (LB, L3 or gateway) are added it is not possible to detach them without stopping the L3, metadata and dhcp services.</div><div><br></div><div>- Deleting a network usually requires 5 to 6 separate CLI calls to teardown each component. The commands to do this are non-intuitive, e.g. to delete a router you must delete all of the ports on it, but you must use the "router-interface-delete" which takes a subnet, not a port.</div>

<div><br></div><div>- To update a subnet, e.g. to fix incorrect allocation pools, you must construct the XML or JSON body of the HTTP request. This is not documented in the command.</div><div><br></div><div>- Then it turns out allocation pools and the CIDR are read-only attributes!</div>

<div><br></div><div>- As far as we can tell, floating IPs must be attached to an ethernet bridge. This is problematic if you're not using ethernet as your link layer (e.g. using infiniband).</div><div><br></div><div>
- Network administration documentation makes confusing and unrealistic assumptions about deployments: create a private network on <a href="http://10.0.1.0/24">10.0.1.0/24</a> and a "public" one with floating IPs on another RFC 1918 block.</div>

<div><br></div><div>- As previously mentioned on this list, no support for multi-host deployments.</div><div><br></div><div>- The documented OVS deployments place six (yes six!) layers of software bridging between your VM and the public internet.</div>

<div><br></div><div>- Security groups support egress (nice!) but there's no way with the nova commands to allow-all on egress. So users will need to make new security groups before they migrate.</div><div><br></div><div>

- Little to no support in IRC from the neutron devs (on multiple occasions).</div><div><br></div><div>I am sure that many of these issues have straightforward solutions, but nova-network works fine for us now. The only thing driving us into neutron is the threat of nova-network's deprecation.</div>

<div><br></div><div>This really feels like second-system syndrome to me.</div></div>