Open Stack

On Mon, Jan 14, 2013 at 12:43:07PM -0800, Dan Wendlandt wrote:
> 
> 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).

I don't strong opinion about the specific format of the Quantum -> Nova data.
What is ultimately important is the data model defined for the Nova virt drivers
in nova/network/model.py, the VIF & Network classes. These are the integration
point between the Nova network API driver and the virt drivers. The important
thing is that the per-hypervisor VIF driver impls must be fully isolated from
the implementation details of the network API driver.

As an example, when configuring OpenVSwitch one of the pieces of information
require is an 'interfaceid'. Previously the libvirt VIF driver set the interfaceid
based on the vif['uuid'] field, since that is what quantum expected. This is not
portable though. The correct approach is for nova.network.model to have an
explicit 'ovs-interfaceid' field and the nova.network.quantumv2.api driver
sets this based on the on vif['uuid']. The libvirt VIF driver can now configure
OVS with any network driver, not simply Quantum. Similarly for things like the
OVS bridge name, of the TAP device names, all of which previously had to be
hardcoded to Quantum specific data. This extends to bridging, 801.qbh, etc,etc

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

I don't believe anything I have done is intentionally libvirt specific. If
some of it is, I'm happy to have that pointed out so we can adjust it to be
more generally applicable. If the Quantum data seems the same as the libvirt
XML data model it is only because the libvirt data model is already written
to be portable as as many hypervisors as possible - the Nova virt abstraction
layer is really just re-inventing the same thing. As such I expect the data
that Nova needs for VIFs to be pretty much the same as that libvirt reuqires
for VIFs. The  set of metadata for the different types of VIF that I consider
to be the bare minimum can be seen here:

  https://review.openstack.org/#/c/19128/6/nova/network/model.py

The bottom line is that this should allow all Quantum specific logic should
be isolated in the  nova.network.quantumv2.api driver, and not leak out into
the VIF impls of the virt drivers.

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

Whether libvirt has support for this or not has no bearing on Quantum. It
is purely an impl detail for the libvirt VIF driver - the following change
demonstrates this

   https://review.openstack.org/#/c/19125/

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

The patches I've written so far will allow a Grizzly based Nova to talk
to a Folsom based Quantum - you'll simply have to configure the old VIF
driver classes as Nova have in Folsom. Meanwhile a Grizzly release of
Nova will be able to talk to a Grizzly release of Quantum. What won't
neccessarily work is random development snapshots of Quantum & Nova.

In general, for the future, Nova should treat any new fields as optional,
so if Quantum does not provide them, Nova should fallback to some sensible
back-compatible behaviour.

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