Well in terms of the ovs plugin change for strategy 2 that requires a single function call Here: https://github.com/openstack/os-vif/blob/master/vif_plug_ovs/ovs.py#L109 And here: https://github.com/openstack/os-vif/blob/master/vif_plug_ovs/ovs.py#L84 and one new function in https://github.com/openstack/os-vif/blob/master/vif_plug_ovs/linux_net.py with unit test it probably <100 lines of code.
For strategy 1 we would need to do a little more work as we would have to pass two bridges but as you said creating the bridge if it does not exist is needed in either case. From: Kevin Benton [mailto:ke...@benton.pub] Sent: Tuesday, June 14, 2016 10:49 AM To: Daniel P. Berrange <berra...@redhat.com> Cc: openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] [Neutron][os-vif] Expanding vif capability for wiring trunk ports Yep, and both strategies depend on that "create if not exists" logic so it makes sense to at least get that implemented while we continue to argue about which strategy to use. On Jun 14, 2016 02:43, "Daniel P. Berrange" <berra...@redhat.com<mailto:berra...@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 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
