[openstack-dev] [Quantum] Re: openvswitch provider patch
rkukura at redhat.com
Wed Sep 5 20:41:18 UTC 2012
On 09/04/2012 01:14 PM, Robert Kukura wrote:
> On 09/03/2012 04:35 PM, Robert Kukura wrote:
>> [For those on openstack-dev, this is a discussion of the desired default
>> behavior of the openvswitch plugin, which has changed somewhat with the
>> recent provider network implementation. Specifically, normal "tenant"
>> networks default to VLAN networks, which now require pre-configuration
>> of an OVS bridge for the physical network on each node where the agent
>> runs. Devstack by default configures openvswitch to use GRE tunnels
>> instead, as before, but tunnels require kernel support not in some
>> operating systems. See http://wiki.openstack.org/ConfigureOpenvswitch
>> for a description of the current openvswitch plugin configuration.]
>> On 09/03/2012 02:00 PM, Dan Wendlandt wrote:
>>> I think we agree on the high-level goal of having a default setup that
>>> does not require extra configuration that is not done automatically by
>>> In my thinking, using VLAN mode requires an understanding of which
>>> physical network the traffic will go out onto, because we must provide
>>> OVS with a range of VLANs that we already know that they are available
>>> to be trunked on that physical network. Thus, it doesn't really make
>>> sense to allocate VLAN networks prior to knowing the physical network.
>> That is a very good point. I completely agree. To me, this means we
>> should not create
>>> In tunnel mode, the segmentation_id is completely decoupled from the
>>> physical network, meaning they can be assigned before the admin even
>>> needs to think about multiple hosts and which physical network is in
>>> use. With this in mind, I would argue that the code should probably
>>> default to creating tunnel networks.
>> I agree, assuming VLANs and GRE networks are the only options.
>>> One option would be to have a
>>> distro that does not support tunneling default to using VLANs, though
>>> that distro would also likely have to automate the creation of the
>>> external bridge, as I think defaulting to vlans without automating the
>>> creation of the external bridge will lead to a lot of usability
>>> complaints (the one thing I'm really sensitive to is people getting
>>> the impression that quantum is 'busted' and then being scared away
>>> from it more permemently).
>> I agree defaulting to VLANs would require auto-configuration of the
>> bridge to achieve the single-box zero-config objective.
>> I'm very hesitant to try to make the defaults or anything else dependent
>> on whether the OS supports OVS tunnels. This would just add confusion
>> and complexity. In the long run, I expect OVS tunnel support will be
>> moved into the Linux kernel source tree, and we'll just have to switch
>> from using patch ports to using veths to make it work, at least on OSes
>> with up-to-date kernels.
>> Other than defaulting to this sort of auto-configuring VLAN bridge
>> approach, I can think of two other options:
>> 1) Default to allocating tenant networks as GRE networks, and make sure
>> they work at least locally on OSes that do not support OVS tunnels. I
>> think we'd mainly just have to detect the error when creating the patch
>> port for the tunnel bridge, log the error, and continue. We'd probably
>> also want to log an error every time the agent tried to bring up a GRE
>> network. I'd generally prefer to have the agent exit when the tunnel
>> bridge could not be properly configured, but logging and continuing may
>> be acceptable. But I'm also thinking about non-uniform connectivity
>> scenarios where some nodes support GRE tunnels and other do not - we
>> don't want the agent to exit in that case.
>> 2) We could introduce a new "local" provider:network_type that
>> explicitly does not span systems. These networks would use the
>> integration bridge with OVS, allowing communication between VMs and
>> agents on the local host, but no external communication. This
>> network_type would not require any segmentation_id to be allocated, and
>> therefore not need a pool for allocation. A configuration flag in the
>> plugin, defaulting to True, would cause tenant networks to be allocated
>> as this network type. This seems like a clean solution, and very little
>> work to implement, but it may just seem too odd to have this sort of
>> network_type in quantum.
> A concrete WIP patch implementing the above is at
> https://review.openstack.org/#/c/12362. Please take a look and provide
> feedback. This provides the single-box zero-configuration use case, and
> makes configuring any actual network resources more explicit, since
> there are no assumptions about the environment built into default
> configuration values any more.
A corresponding WIP devstack patch is now available at
https://review.openstack.org/#/c/12456/. Please provide feedback here or
More information about the OpenStack-dev