Open Stack

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.

On Tue, Jun 14, 2016 at 2:30 AM, Daniel P. Berrange <berrange at redhat.com>
wrote:

> On Tue, Jun 14, 2016 at 02:10:52AM -0700, Kevin Benton wrote:
> > Strategy 1 is being pitched to make it easier to implement with the
> current
> > internals of the Neutron OVS agent (using integration bridge plugging
> > events). I'm not sure that's better architecturally long term because the
> > OVS agent has to have logic to wire up patch ports for the sub-interfaces
> > anyway, so having the logic to make it wire up patch port for the parent
> > interface is not out of place.
> >
> > Also consider that we will now have to tell os-vif two bridges to use if
> we
> > go with strategy 1. One bridge to create and attach the VM to, and
> another
> > for the other half of the patch port. This means that we are going to
> have
> > to leak more details of what Neutron is doing into the VIF details of the
> > neutron port data model and relay that to Nova...
>
> It sounds like strategy 2 also requires you to pass a second bridge
> name to nova/os-vif, unless I'm mis-understanding the description
> below.
>
>
> > On Tue, Jun 14, 2016 at 1:29 AM, Daniel P. Berrange <berrange at redhat.com
> >
> > wrote:
> >
> > > On Mon, Jun 13, 2016 at 11:35:17PM +0000, Peters, Rawlin wrote:
> > > > That said, there are currently a couple of vif-plugging strategies
> > > > we could go with for wiring trunk ports for OVS, each of them
> > > > requiring varying levels of os-vif augmentation:
> > > >
> > > > Strategy 1) When Nova is plugging a trunk port, it creates the OVS
> > > > trunk bridge, attaches the tap to it, and creates one patch port
> > > > pair from the trunk bridge to br-int.
> > > >
> > > > Strategy 2) Neutron passes a bridge name to Nova, and Nova uses this
> > > > bridge name to create the OVS trunk bridge and attach the tap to it
> > > > (no patch port pair plugging into br-int).
> > >
> > > [snip]
> > >
> > > > If neither of these strategies would be in danger of not making it
> > > > into the Newton release, then I think we should definitely opt for
> > > > Strategy 1 because it leads to a simpler overall solution. If only
> > > > Strategy 2 is feasible enough to make it into os-vif for Newton,
> > > > then we need to know ASAP so that we can start implementing the
> > > > required functionality for the OVS agent to monitor for dynamic trunk
> > > > bridge creation/deletion.
> > >
> > > IMHO the answer should always be to go for the right long term
> > > architectural
> > > solution, not take short cuts just to meet some arbitrary deadline,
> because
> > > that will compromise the code over the long term. From what you are
> saying
> > > it sounds like strategy 1 is the optimal long term solution, so that
> should
> > > be where effort is focused regardless.
> > >
> > > Regards,
> > > Daniel
> > > --
> > > |: http://berrange.com      -o-
> http://www.flickr.com/photos/dberrange/
> > > :|
> > > |: http://libvirt.org              -o-
> http://virt-manager.org
> > > :|
> > > |: http://autobuild.org       -o-
> http://search.cpan.org/~danberr/
> > > :|
> > > |: http://entangle-photo.org       -o-
> http://live.gnome.org/gtk-vnc
> > > :|
> > >
> > >
> __________________________________________________________________________
> > > 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
> > >
>
> Regards,
> Daniel
> --
> |: http://berrange.com      -o-    http://www.flickr.com/photos/dberrange/
> :|
> |: http://libvirt.org              -o-             http://virt-manager.org
> :|
> |: http://autobuild.org       -o-         http://search.cpan.org/~danberr/
> :|
> |: http://entangle-photo.org       -o-       http://live.gnome.org/gtk-vnc
> :|
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160614/29a4eb5e/attachment.html>