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 <berra...@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-requ...@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 :| __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
