Open Stack

Sorry folks, my wife + baby were sick last week, so I mostly dropped
offline.  Some comments below.

Adding the broader ML, as I think this has larger implications,
particularly for those using non-libvirt platforms with Quantum.

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.

On Tue, Jan 8, 2013 at 1:39 AM, Daniel P. Berrange <berrange at redhat.com>wrote:

> On Tue, Jan 08, 2013 at 01:12:05AM -0800, Dan Wendlandt wrote:
> > The circle I haven't quite been able to square yet is how to avoid making
> > the generic Quantum API specific to a particular virt layer (e.g.,
> > libvirt), but also prevent the API from devolving into a "throw whatever
> > k-v pairs the virt layer needs" in a dict mess that nova seems to all too
> > fond of.
>
> The latter is exactly what we should be doing in Nova. The virt drivers
> do not/should not have any knowledge of what networking service is being
> used with Nova. Whether it uses Quantum or Nova networking, or something
> else, the information required to connect a guest VIF to an OVS bridge
> is always the same. You need to the bridge name + the interfaceid port
> profile parameter. This isn't specific to either libvirt or Quantum.
> It isn't just an ad-hoc dict though - it is a formally defined VIF class
> with designated required parameters for each vif_type:
>
>   https://review.openstack.org/#/c/19128/2/nova/network/model.py
>
> The key benefit of the VIF driver impl in that change is that it is
> totally plug+play for all networking types. You don't need to configure
> the 'libvirt_vif_driver' parameter at all anymore. It will just figure
> out the right thing based on the metadata provided in the VIF config
> dict.
>

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).

To get back to my original point, the spec
http://wiki.openstack.org/LibvirtVIFDrivers envisions Quantum returning
data that to me maps quite closely to what can be specific in a libvirt
<interface> object (http://libvirt.org/formatdomain.html).  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.

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.

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.

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:
https://review.openstack.org/#/c/19542/3/quantum/extensions/portbindings.py).
 In this case, Nova should probably be checking the version of this
extension that is running to know what k-v pairs to expect.

Thanks,

Dan




>
> 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:|
>



-- 
~~~~~~~~~~~~~~~~~~~~~~~~~~~
Dan Wendlandt
Nicira, Inc: www.nicira.com
twitter: danwendlandt
~~~~~~~~~~~~~~~~~~~~~~~~~~~
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20130114/bb543396/attachment.html>