<div dir="ltr">Let me write a spec and see what you both think.  I have a couple of things we could address here and while it's a bit late it wouldn't be a dramatic thing to fix and it might be acceptable.<br></div><div class="gmail_extra"><br><div class="gmail_quote">On 15 December 2014 at 11:28, Daniel P. Berrange <span dir="ltr"><<a href="mailto:berrange@redhat.com" target="_blank">berrange@redhat.com</a>></span> wrote:<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On Mon, Dec 15, 2014 at 11:15:56AM +0100, Ian Wells wrote:<br>
> Hey Ryota,<br>
><br>
> A better way of describing it would be that the bridge name is, at present,<br>
> generated in *both* Nova *and* Neutron, and the VIF type semantics define<br>
> how it's calculated.  I think you're right that in both cases it would make<br>
> more sense for Neutron to tell Nova what the connection endpoint was going<br>
> to be rather than have Nova calculate it independently.  I'm not sure that<br>
> that necessarily requires two blueprints, and you don't have a spec there<br>
> at the moment, which is a problem because the Neutron spec deadline is upon<br>
> us, but the idea's a good one.  (You might get away without a Neutron spec,<br>
> since the change to Neutron to add the information should be small and<br>
> backward compatible, but that's not something I can make judgement on.)<br>
<br>
</span>Yep, the fact that both Nova & Neutron calculat the bridge name is a<br>
historical accident. Originally Nova did it, because nova-network was<br>
the only solution. Then Neutron did it too, so it matched what Nova<br>
was doing. Clearly if we had Neutron right from the start, then it<br>
would have been Neutrons responsibility todo this. Nothing in Nova<br>
cares what the names are from a functional POV - it just needs to<br>
be told what to use.<br>
<br>
Regards,<br>
Daniel<br>
<span class="HOEnZb"><font color="#888888">--<br>
|: <a href="http://berrange.com" target="_blank">http://berrange.com</a>      -o-    <a href="http://www.flickr.com/photos/dberrange/" target="_blank">http://www.flickr.com/photos/dberrange/</a> :|<br>
|: <a href="http://libvirt.org" target="_blank">http://libvirt.org</a>              -o-             <a href="http://virt-manager.org" target="_blank">http://virt-manager.org</a> :|<br>
|: <a href="http://autobuild.org" target="_blank">http://autobuild.org</a>       -o-         <a href="http://search.cpan.org/~danberr/" target="_blank">http://search.cpan.org/~danberr/</a> :|<br>
|: <a href="http://entangle-photo.org" target="_blank">http://entangle-photo.org</a>       -o-       <a href="http://live.gnome.org/gtk-vnc" target="_blank">http://live.gnome.org/gtk-vnc</a> :|<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</div></div></blockquote></div></div>