Open Stack

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

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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160614/1188e30f/attachment.html>