Open Stack

On Tue, Dec 09, 2014 at 10:53:19AM +0100, Maxime Leroy wrote:
> I have also proposed a blueprint to have a new plugin mechanism in
> nova to load external vif driver. (nova-specs:
> https://review.openstack.org/#/c/136827/ and nova (rfc patch):
> https://review.openstack.org/#/c/136857/)
> 
> From my point-of-view of a developer having a plugin framework for
> internal/external vif driver seems to be a good thing.
> It makes the code more modular and introduce a clear api for vif driver classes.
> 
> So far, it raises legitimate questions concerning API stability and
> public API that request a wider discussion on the ML (as asking by
> John Garbut).
> 
> I think having a plugin mechanism and a clear api for vif driver is
> not going against this policy:
> http://docs.openstack.org/developer/nova/devref/policies.html#out-of-tree-support.
> 
> There is no needs to have a stable API. It is up to the owner of the
> external VIF driver to ensure that its driver is supported by the
> latest API. And not the nova community to manage a stable API for this
> external VIF driver. Does it make senses ?

Experiance has shown that even if it is documented as unsupported, once
the extension point exists, vendors & users will ignore the small print
about support status. There will be complaints raised every time it gets
broken until we end up being forced to maintain it as stable API whether
we want to or not. That's not a route we want to go down.

> Considering the network V2 API, L2/ML2 mechanism driver and VIF driver
> need to exchange information such as: binding:vif_type and
> binding:vif_details.
> 
> From my understanding, 'binding:vif_type' and 'binding:vif_details' as
> a field part of the public network api. There is no validation
> constraints for these fields (see
> http://docs.openstack.org/api/openstack-network/2.0/content/binding_ext_ports.html),
> it means that any value is accepted by the API. So, the values set in
> 'binding:vif_type' and 'binding:vif_details' are not part of the
> public API. Is my understanding correct ?

The VIF parameters are mapped into the nova.network.model.VIF class
which is doing some crude validation. I would anticipate that this
validation will be increasing over time, because any functional data
flowing over the API and so needs to be carefully managed for upgrade
reasons.

Even if the Neutron impl is out of tree, I would still expect both
Nova and Neutron core to sign off on any new VIF type name and its
associated details (if any).

> What other reasons am I missing to not have VIF driver classes as a
> public extension point ?

Having to find & install VIF driver classes from countless different
vendors, each hiding their code away in their own obsecure website,
will lead to awful end user experiance when deploying Nova. Users are
better served by having it all provided when they deploy Nova IMHO

If every vendor goes off & works in their own isolated world we also
loose the scope to align the implementations, so that common concepts
work the same way in all cases and allow us to minimize the number of
new VIF types required. The proposed vhostuser VIF type is a good
example of this - it allows a single Nova VIF driver to be capable of
potentially supporting multiple different impls on the Neutron side.
If every vendor worked in their own world, we would have ended up with
multiple VIF drivers doing the same thing in Nova, each with their own
set of bugs & quirks.

I expect the quality of the code the operator receives will be lower
if it is never reviewed by anyone except the vendor who writes it in
the first place.

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