Open Stack

>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.

>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.

>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.

>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. :)


1.
https://github.com/openstack/neutron/blob/f78e5b4ec812cfcf5ab8b50fca62d1ae0dd7741d/neutron/agent/linux/iptables_firewall.py#L919-L923

On Tue, Jun 14, 2016 at 9:49 AM, Peters, Rawlin <rawlin.peters at hpe.com>
wrote:

> On Tuesday, June 14, 2016 3:43 AM, Daniel P. Berrange (berrange at 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160614/04c2aab8/attachment.html>