<div dir="ltr">><span style="font-size:12.8px">I wouldn't say linux bridges are totally outside of its domain because it relies </span><span style="font-size:12.8px">on them for security groups.</span><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">It relies on a side effect of their existence - iptables rules being applied to the veth interface. It does nothing to the actual linux bridge itself. If there was a way to plug a veth directly between the VM and OVS and have iptables be applied, there would be *no* code changes on the OVS agent because it doesn't do anything with the bridge.</span><br></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">then use the equivalent of "ovs-vsctl iface-to-br <peer name>" </span><span style="font-size:12.8px">to get the name of the bridge.</span></div><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">So then we have to have logic to guess which bridges connected by patch ports 'belong' to trunk ports because we weren't explicit anywhere.</span></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Jun 15, 2016 at 11:01 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>On Tuesday, June 14, 2016 6:27 PM, Kevin Benton (kevin@benton.pub) wrote:<br>
> >which generates an arbitrary name<br>
><br>
> I'm not a fan of this approach because it requires coordinated assumptions.<br>
> With the OVS hybrid plug strategy we have to make guesses on the agent side<br>
> about the presence of bridges with specific names that we never explicitly<br>
> requested and that we were never explicitly told about. So we end up with code<br>
> like [1] that is looking for a particular end of a veth pair it just hopes is<br>
> there so the rules have an effect.<br>
<br>
</span>I don't think this should be viewed as a downside of Strategy 1 because, at<br>
least when we use patch port pairs, we can easily get the peer name from the<br>
port on br-int, then use the equivalent of "ovs-vsctl iface-to-br <peer name>"<br>
to get the name of the bridge. If we allow supporting veth pairs to implement<br>
the subports, then getting the arbitrary trunk bridge/veth names isn't as<br>
trivial.<br>
<br>
This also brings up the question: do we even need to support veth pairs over<br>
patch port pairs anymore? Are there any distros out there that support<br>
openstack but not OVS patch ports?<br>
<span><br>
><br>
> >it seems that the LinuxBridge implementation can simply use an L2 agent<br>
> >extension for creating the vlan interfaces for the subports<br>
><br>
> LinuxBridge implementation is the same regardless of the strategy for OVS. The<br>
> whole reason we have to come up with these alternative approaches for OVS is<br>
> because we can't use the obvious architecture of letting it plug into the<br>
> integration bridge due to VLANs already being used for network isolation. I'm<br>
> not sure pushing complexity out to os-vif to deal with this is a great<br>
> long-term strategy.<br>
<br>
</span>The complexity we'd be pushing out to os-vif is not much worse than the current<br>
complexity of the hybrid_ovs strategy already in place today.<br>
<span><br>
><br>
> >Also, we didn’t make the OVS agent monitor for new linux bridges in the<br>
> >hybrid_ovs strategy so that Neutron could be responsible for creating the veth<br>
> >pair.<br>
><br>
> Linux Bridges are outside of the domain of OVS and even its agent. The L2 agent<br>
> doesn't actually do anything with the bridge itself, it just needs a veth<br>
> device it can put iptables rules on. That's in contrast to these new OVS<br>
> bridges that we will be managing rules for, creating additional patch ports,<br>
> etc.<br>
<br>
</span>I wouldn't say linux bridges are totally outside of its domain because it relies<br>
on them for security groups. Rather than relying on an arbitrary naming<br>
convention between Neutron and Nova, we could've implemented monitoring for new<br>
linux bridges to create veth pairs and firewall rules on. I'm glad we didn't,<br>
because that logic is specific to that particular firewall driver, similar to<br>
how this trunk bridge monitoring would be specific to only vlan-aware-vms. I<br>
think the logic lives best within an L2 agent extension, outside of the core<br>
of the OVS agent.<br>
<span><br>
><br>
> >Why shouldn't we use the tools that are already available to us?<br>
><br>
> Because we're trying to build a house and all we have are paint brushes. :)<br>
<br>
</span>To me it seems like we already have a house that just needs a little paint :)<br>
<br>
><br>
><br>
> 1.<br>
> <a href="https://github.com/openstack/neutron/blob/f78e5b4ec812cfcf5ab8b50fca62d1ae0dd7741d/neutron/agent/linux/iptables_firewall.py#L919-L923" rel="noreferrer" target="_blank">https://github.com/openstack/neutron/blob/f78e5b4ec812cfcf5ab8b50fca62d1ae0dd7741d/neutron/agent/linux/iptables_firewall.py#L919-L923</a><br>
</blockquote></div><br></div></div>