Open Stack

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