Open Stack

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

-Bob

> 
> Any thoughts on either of these options vs. trying to auto-configure
> VLAN bridges? I'm including openstack-dev, and would welcome input from
> others as well.
> 
>>
>> Regardless of the default, I definitely agree that we want to make
>> sure the agent fails cleanly (and loudly) if it is config says to use
>> tunnels, but the OVS version being used does not support tunnels.
>> There should probably be a check at the start of the agent to do so,
>> does that make sense?   I suspect we could just try to create a port
>> of type = 'gre', and if that fails, conclude that tunneling is not
>> supported.
> 
> I was thinking of just looking for an error when creating the patch port
> as the first indication GRE networks would not be supported. As you say,
> I'd prefer to have the agent "fail cleanly", but we if we go with option
> 1 above, we'd need to settle for "loudly".
> 
>>
>>>>
>>>> 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.
>>>
>>> I agree we want this basic use case to work without altering the default
>>> configuration.
>>
>> Agreed, I think that's the most important point.  Thanks,
>>
>> Dan
> 
> No problem. I should have tried to get a discussion going on the default
> configuration much earlier in the provider network development, but
> thought the defaults would turn out to be close enough to the previous
> ones to not be an issue.
> 
> -Bob
> 
> 
> 
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>