<div dir="ltr">><span style="font-size:12.8px">which generates an arbitrary name</span><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">I'm not a fan of this approach because it requires coordinated assumptions. With the OVS hybrid plug strategy we have to make guesses on the agent side about the presence of bridges with specific names that we never explicitly requested and that we were never explicitly told about. So we end up with code like [1] that is looking for a particular end of a veth pair it just hopes is there so the rules have an effect.</span></div><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">></span><span style="font-size:12.8px">it seems that the LinuxBridge implementation can simply use an L2 agent extension for creating the vlan interfaces for the subports</span></div><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">LinuxBridge implementation is the same regardless of the strategy for OVS. The whole reason we have to come up with these alternative approaches for OVS is because we can't use the obvious architecture of letting it plug into the integration bridge due to VLANs already being used for network isolation. I'm not sure pushing complexity out to os-vif to deal with this is a great long-term strategy.</span></div><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">></span><span style="font-size:12.8px">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.</span></div><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">Linux Bridges are outside of the domain of OVS and even its agent. The L2 agent doesn't actually do anything with the bridge itself, it just needs a veth device it can put iptables rules on. That's in contrast to these new OVS bridges that we will be managing rules for, creating additional patch ports, etc.</span></div><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">></span><span style="font-size:12.8px">Why shouldn't we use the tools that are already available to us?</span></div><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">Because we're trying to build a house and all we have are paint brushes. :)</span></div><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">1. <a href="https://github.com/openstack/neutron/blob/f78e5b4ec812cfcf5ab8b50fca62d1ae0dd7741d/neutron/agent/linux/iptables_firewall.py#L919-L923">https://github.com/openstack/neutron/blob/f78e5b4ec812cfcf5ab8b50fca62d1ae0dd7741d/neutron/agent/linux/iptables_firewall.py#L919-L923</a></span></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Jun 14, 2016 at 9:49 AM, Peters, Rawlin <span dir="ltr"><<a href="mailto:rawlin.peters@hpe.com" target="_blank">rawlin.peters@hpe.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On Tuesday, June 14, 2016 3:43 AM, Daniel P. Berrange (<a href="mailto:berrange@redhat.com">berrange@redhat.com</a>) wrote:<br>
><br>
> On Tue, Jun 14, 2016 at 02:35:57AM -0700, Kevin Benton wrote:<br>
> > In strategy 2 we just pass 1 bridge name to Nova. That's the one that<br>
> > is ensures is created and plumbs the VM to. Since it's not responsible<br>
> > for patch ports it doesn't need to know anything about the other bridge.<br>
><br>
> Ok, so we're already passing that bridge name - all we need change is make<br>
> sure it is actuall created if it doesn't already exist ? If so that sounds simple<br>
> enough to add to os-vif - we already have exactly the same logic for the<br>
> linux_bridge plugin<br>
<br>
</span>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.<br>
<br>
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.<br>
<br>
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.<br>
<br>
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?<br>
<br>
Regards,<br>
Rawlin<br>
</blockquote></div><br></div>