Sorry folks, my wife + baby were sick last week, so I mostly dropped offline. Some comments below. <div><br></div><div>Adding the broader ML, as I think this has larger implications, particularly for those using non-libvirt platforms with Quantum. </div>
<div><br></div><div>For those joining the discussion, we're talking about how to use communication between Nova + Quantum during VM boot to eliminate the step of configuring Nova with a vif-plugging type that is compatible with your Quantum plugin. <br>
<br><div class="gmail_quote">On Tue, Jan 8, 2013 at 1:39 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"><div>On Tue, Jan 08, 2013 at 01:12:05AM -0800, Dan Wendlandt wrote:<br>
> The circle I haven't quite been able to square yet is how to avoid making<br>
> the generic Quantum API specific to a particular virt layer (e.g.,<br>
> libvirt), but also prevent the API from devolving into a "throw whatever<br>
> k-v pairs the virt layer needs" in a dict mess that nova seems to all too<br>
> fond of.<br>
<br>
</div>The latter is exactly what we should be doing in Nova. The virt drivers<br>
do not/should not have any knowledge of what networking service is being<br>
used with Nova. Whether it uses Quantum or Nova networking, or something<br>
else, the information required to connect a guest VIF to an OVS bridge<br>
is always the same. You need to the bridge name + the interfaceid port<br>
profile parameter. This isn't specific to either libvirt or Quantum.<br>
It isn't just an ad-hoc dict though - it is a formally defined VIF class<br>
with designated required parameters for each vif_type:<br>
<br>
<a href="https://review.openstack.org/#/c/19128/2/nova/network/model.py" target="_blank">https://review.openstack.org/#/c/19128/2/nova/network/model.py</a><br>
<br>
The key benefit of the VIF driver impl in that change is that it is<br>
totally plug+play for all networking types. You don't need to configure<br>
the 'libvirt_vif_driver' parameter at all anymore. It will just figure<br>
out the right thing based on the metadata provided in the VIF config<br>
dict.<br></blockquote><div><br></div><div>I think we agree on both goals and mechanism at a high-level. The point I was trying to make above is whether we have a FORMAL Quantum API definition of what keys are included in this dictionary, and how this set of values changes over time (in the "bad old days", many of the interfaces within nova where just python dictionaries, where the only "definition" of what they contained was the code that shoved k-v pairs into them... that is what I want to avoid). </div>
<div><br></div><div>To get back to my original point, the spec <a href="http://wiki.openstack.org/LibvirtVIFDrivers">http://wiki.openstack.org/LibvirtVIFDrivers</a> envisions Quantum returning data that to me maps quite closely to what can be specific in a libvirt <interface> object (<a href="http://libvirt.org/formatdomain.html">http://libvirt.org/formatdomain.html</a>). The conflict is that the current Quantum API is currently generic across all hypervisor platforms (xenserver, esx, hyper-v). Does it make sense for Quantum to return these fields if a virt drivers is enabled? What about other platforms that may have key-value pairs that they can use but do not make sense to libvirt? I think garyk had expressed similar concerns. </div>
<div><br></div><div>Either we need to try and create a generic representation of vif-data that applies across all virt layers (seems likely to be a mess, but I could be wrong) or we actually just have Quantum be able to run a set of such API extensions, and a plugin can expose the set of extensions for the Nova virt-layers they support. In that sense, what you've written up, and the corresponding Quantum changes, could be seen as the libvirt-specific admin API extension for provisioning VIFs in Nova. It may be that this was the goal all along from your end, but it wasn't how the conversation started out on the Quantum team, which may be part of the confusion. </div>
<div><br></div><div>Another interesting issue that I'd like to see discussed in the spec is versioning as new network capabilities are added to a particular platform like libvirt. It seems like Quantum may need to know more about the capabilities of the virt-layer itself in order to know what to pass back. An existing example of this is the fact that the libvirt XML constructs for OVS are only available in libvirt 0.9.11. If someone was using a old version, presumably the port creation operation should either fall back to using something that was available (e.g., plain bridge) or fail. </div>
<div><br></div><div>There's also the opposite direction, which is how Nova knows whether the corresponding Quantum server is running a updated enough version to have all of the key-value pairs it expects (for example, it looks like a recent commit just extended garyk's original extension: <a href="https://review.openstack.org/#/c/19542/3/quantum/extensions/portbindings.py">https://review.openstack.org/#/c/19542/3/quantum/extensions/portbindings.py</a>). In this case, Nova should probably be checking the version of this extension that is running to know what k-v pairs to expect. </div>
<div><br></div><div>Thanks,</div><div><br></div><div>Dan</div><div><br></div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Regards,<br>
<div><div>Daniel<br>
--<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>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br>~~~~~~~~~~~~~~~~~~~~~~~~~~~<br>Dan Wendlandt <div>Nicira, Inc: <a href="http://www.nicira.com" target="_blank">www.nicira.com</a><br><div>twitter: danwendlandt<br>
~~~~~~~~~~~~~~~~~~~~~~~~~~~<br></div></div>
</div>