Open Stack

On Wed, Jun 15, 2016 at 2:01 PM, Peters, Rawlin <rawlin.peters at hpe.com> wrote:
> On Tuesday, June 14, 2016 6:27 PM, Kevin Benton (kevin at 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-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev