revisit provider-net defaults for OVS (and LB?)
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
neutron |
Fix Released
|
Medium
|
Robert Kukura |
Bug Description
the existing defaults for the OVS plugin assume a br-eth1 has been created, which is not backward compatible and generally makes assumptions about the users physical subnet.
We're discussing the right approach, but it seems like we should have an option where someone can run quantum in a single node setup where there is isolation on the br-int, without having to specify external config info.
From email:
Here's my assumption about how people will use quantum. Many will
first try it on a single box, where neither an external interface or
tunnel-IP is required. Once they then want to move to a realistic
setup, they will either need to use tunneling (specify tunnel-ip and
you're done) or vlans (specify vlan interface, vlan range, and trunk
vlans on the physical switches).
That is, the 'basic' use case is single box, meaning no config of an
external bridge or tunnel-ip is needed. This is how the plugin at
least used to work.
Changed in quantum: | |
assignee: | nobody → Robert Kukura (rkukura) |
status: | New → Confirmed |
milestone: | none → folsom-rc1 |
importance: | Undecided → Critical |
Changed in quantum: | |
importance: | Critical → High |
Changed in quantum: | |
importance: | High → Medium |
Changed in quantum: | |
status: | Fix Committed → Fix Released |
Changed in quantum: | |
milestone: | folsom-rc1 → 2012.2 |
We seem to have the following options:
1) Leave things pretty much as-is, depending on devstack to configure a basic single-box deployment. This currently works on Ubuntu using GRE tunnels, but doesn't provide a single-box zero-config environment when not using devstack, or even with devstack on Fedora. Devstack could be updated to use VLANs instead on Fedora or other operating systems where OVS GRE tunnels are not supported.
2) Leave the openvswitch defaults pretty much as-is, using VLANs on a physical network called "default" that is mapped by default to br-eth1, but change the openvswitch agent to create the bridge automatically if it doesn't already exist, with no physical interface. The downsides of this are that these defaults are rarely correct and automatically creating the physical network bridge hides serious configuration errors in real deployments.
3) Implement a new "local" provider: network_ type where there is explicitly no external connectivity, and make this network type the default for tenant networks. The basic single-box zero-config use case would work the same everywhere, but configuration changes would be needed for all multi-host deployments.