On Tuesday, June 14, 2016 3:43 AM, Daniel P. Berrange (berra...@redhat.com) wrote: > > On Tue, Jun 14, 2016 at 02:35:57AM -0700, Kevin Benton wrote: > > In strategy 2 we just pass 1 bridge name to Nova. That's the one that > > is ensures is created and plumbs the VM to. Since it's not responsible > > for patch ports it doesn't need to know anything about the other bridge. > > Ok, so we're already passing that bridge name - all we need change is make > sure it is actuall created if it doesn't already exist ? If so that sounds > simple > enough to add to os-vif - we already have exactly the same logic for the > linux_bridge plugin
Neutron doesn't actually pass the bridge name in the vif_details today, but Nova will use that bridge rather than br-int if it's passed in the vif_details. In terms of strategy 1, I was still only envisioning one bridge name getting passed in the vif_details (br-int). The "plug" action is only a variation of the hybrid_ovs strategy I mentioned earlier, which generates an arbitrary name for the linux bridge, uses that bridge in the instance's libvert XML config file, then creates a veth pair between the linux bridge and br-int. Like hybrid_ovs, the only bridge Nova/os-vif needs to know about is br-int for Strategy 1. In terms of architecture, we get KISS with Strategy 1 (W.R.T. the OVS agent, which is the most complex piece of this IMO). Using an L2 agent extension, we will also get DRY as well because it seems that the LinuxBridge implementation can simply use an L2 agent extension for creating the vlan interfaces for the subports. Similar to how QoS has different drivers for its L2 agent extension, we could have different drivers for OVS and LinuxBridge within the 'trunk' L2 agent extension. Each driver will want to make use of the same RPC calls/push mechanisms for subport creation/deletion. Also, we didn’t make the OVS agent monitor for new linux bridges in the hybrid_ovs strategy so that Neutron could be responsible for creating the veth pair. Was that a mistake or just an instance of KISS? Why shouldn't we use the tools that are already available to us? Regards, Rawlin __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
