<div dir="ltr">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.<div><br></div><div>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...</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Jun 14, 2016 at 1:29 AM, Daniel P. Berrange <span dir="ltr"><<a href="mailto:berrange@redhat.com" target="_blank">berrange@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On Mon, Jun 13, 2016 at 11:35:17PM +0000, Peters, Rawlin wrote:<br>
> That said, there are currently a couple of vif-plugging strategies<br>
> we could go with for wiring trunk ports for OVS, each of them<br>
> requiring varying levels of os-vif augmentation:<br>
><br>
> Strategy 1) When Nova is plugging a trunk port, it creates the OVS<br>
> trunk bridge, attaches the tap to it, and creates one patch port<br>
> pair from the trunk bridge to br-int.<br>
><br>
> Strategy 2) Neutron passes a bridge name to Nova, and Nova uses this<br>
> bridge name to create the OVS trunk bridge and attach the tap to it<br>
> (no patch port pair plugging into br-int).<br>
<br>
</span>[snip]<br>
<span class=""><br>
> If neither of these strategies would be in danger of not making it<br>
> into the Newton release, then I think we should definitely opt for<br>
> Strategy 1 because it leads to a simpler overall solution. If only<br>
> Strategy 2 is feasible enough to make it into os-vif for Newton,<br>
> then we need to know ASAP so that we can start implementing the<br>
> required functionality for the OVS agent to monitor for dynamic trunk<br>
> bridge creation/deletion.<br>
<br>
</span>IMHO the answer should always be to go for the right long term architectural<br>
solution, not take short cuts just to meet some arbitrary deadline, because<br>
that will compromise the code over the long term. From what you are saying<br>
it sounds like strategy 1 is the optimal long term solution, so that should<br>
be where effort is focused regardless.<br>
<span class="im HOEnZb"><br>
Regards,<br>
Daniel<br>
--<br>
|: <a href="http://berrange.com" rel="noreferrer" target="_blank">http://berrange.com</a> -o- <a href="http://www.flickr.com/photos/dberrange/" rel="noreferrer" target="_blank">http://www.flickr.com/photos/dberrange/</a> :|<br>
|: <a href="http://libvirt.org" rel="noreferrer" target="_blank">http://libvirt.org</a> -o- <a href="http://virt-manager.org" rel="noreferrer" target="_blank">http://virt-manager.org</a> :|<br>
|: <a href="http://autobuild.org" rel="noreferrer" target="_blank">http://autobuild.org</a> -o- <a href="http://search.cpan.org/~danberr/" rel="noreferrer" target="_blank">http://search.cpan.org/~danberr/</a> :|<br>
|: <a href="http://entangle-photo.org" rel="noreferrer" target="_blank">http://entangle-photo.org</a> -o- <a href="http://live.gnome.org/gtk-vnc" rel="noreferrer" target="_blank">http://live.gnome.org/gtk-vnc</a> :|<br>
<br>
</span><div class="HOEnZb"><div class="h5">__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</div></div></blockquote></div><br></div>