On Wed, Jun 15, 2016 at 2:01 PM, Peters, Rawlin <rawlin.pet...@hpe.com> wrote: > On Tuesday, June 14, 2016 6:27 PM, Kevin Benton (ke...@benton.pub) wrote: >> >which generates an arbitrary name >> >> 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. > > I don't think this should be viewed as a downside of Strategy 1 because, at > least when we use patch port pairs, we can easily get the peer name from the > port on br-int, then use the equivalent of "ovs-vsctl iface-to-br <peer name>" > to get the name of the bridge. If we allow supporting veth pairs to implement > the subports, then getting the arbitrary trunk bridge/veth names isn't as > trivial. > > This also brings up the question: do we even need to support veth pairs over > patch port pairs anymore? Are there any distros out there that support > openstack but not OVS patch ports?
I really doubt it. This stopped being an issue in Fedora/CentOS/RHEL like 18~ months ago. > >> >> >it seems that the LinuxBridge implementation can simply use an L2 agent >> >extension for creating the vlan interfaces for the subports >> >> 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. > > The complexity we'd be pushing out to os-vif is not much worse than the > current > complexity of the hybrid_ovs strategy already in place today. > >> >> >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. >> >> 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. > > I wouldn't say linux bridges are totally outside of its domain because it > relies > on them for security groups. Rather than relying on an arbitrary naming > convention between Neutron and Nova, we could've implemented monitoring for > new > linux bridges to create veth pairs and firewall rules on. I'm glad we didn't, > because that logic is specific to that particular firewall driver, similar to > how this trunk bridge monitoring would be specific to only vlan-aware-vms. I > think the logic lives best within an L2 agent extension, outside of the core > of the OVS agent. > >> >> >Why shouldn't we use the tools that are already available to us? >> >> Because we're trying to build a house and all we have are paint brushes. :) > > To me it seems like we already have a house that just needs a little paint :) > >> >> >> 1. >> https://github.com/openstack/neutron/blob/f78e5b4ec812cfcf5ab8b50fca62d1ae0dd7741d/neutron/agent/linux/iptables_firewall.py#L919-L923 > __________________________________________________________________________ > 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 __________________________________________________________________________ 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