revisit provider-net defaults for OVS (and LB?)

Bug #1045142 reported by dan wendlandt
6
This bug affects 1 person
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.

dan wendlandt (danwent)
Changed in quantum:
assignee: nobody → Robert Kukura (rkukura)
status: New → Confirmed
milestone: none → folsom-rc1
importance: Undecided → Critical
dan wendlandt (danwent)
Changed in quantum:
importance: Critical → High
Revision history for this message
Robert Kukura (rkukura) wrote :

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.

Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix proposed to quantum (master)

Fix proposed to branch: master
Review: https://review.openstack.org/12362

Changed in quantum:
status: Confirmed → In Progress
dan wendlandt (danwent)
Changed in quantum:
importance: High → Medium
Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix merged to quantum (master)

Reviewed: https://review.openstack.org/12362
Committed: http://github.com/openstack/quantum/commit/88cd4f85047cb8844fd192f3c8d4b087b4085a1a
Submitter: Jenkins
Branch: master

commit 88cd4f85047cb8844fd192f3c8d4b087b4085a1a
Author: Bob Kukura <email address hidden>
Date: Tue Sep 4 12:30:34 2012 -0400

    add local network type and use by default for tenant networks

    Fixes bug 1045142.

    This patch adds 'local' as a new value for provider:network_type,
    supported by the openvswitch and linuxbridge plugins. Networks of this
    type provide connectivity through a bridge for VMs and agents local to
    the host, but no external connectivity. They do not require
    provider:physical_network or provider:segmentation_id values. These
    local networks are intended mainly to support single-box
    zero-configuration testing (including quantum gating), but may have
    other uses as well.

    For openvswitch, the new OVS.tenant_network_type configuration
    variable selects what type of networks are allocated as tenant
    (i.e. non-provider) networks. It defaults to 'local', but must be
    changed to 'vlan' or 'gre' for openvswitch tenant networks to have
    external connectivity. The default value is intended to support
    single-box zero-configuration testing without any need to allocate
    physical network resources or configure bridges, and without requiring
    the operating system to support OVS GRE tunneling. It can also be set
    to 'none' to completely disable creation of tenant networks.

    For linuxbridge, the new VLANS.tenant_network_type configuration
    variable works similarly, with a value of 'vlan' supporting tenant
    networks with external connectivity.

    With either plugin, administrators can create provider local networks
    by specifying "--provider:network_type local". Additionally, with
    openvswitch, provider GRE networks can now be created by specifying
    "--provider:network_type gre --provider:segmentation_id <tunnel-id>".

    A corresponding devstack patch is available at
    https://review.openstack.org/#/c/12456/. With this patch, the
    openvswitch and linuxbridge plugins are by default configured to
    support only local networks. A set of shell variables, documented in
    stack.sh, can be set in localrc to configure remote connectivity,
    including bridges/interfaces available for provider networks.

    Change-Id: I2812548326141d2212d04f34d5448fb974d298e0

Changed in quantum:
status: In Progress → Fix Committed
Thierry Carrez (ttx)
Changed in quantum:
status: Fix Committed → Fix Released
Thierry Carrez (ttx)
Changed in quantum:
milestone: folsom-rc1 → 2012.2
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.