Open Stack

Hi Daniel,
Please see inline

-----Original Message-----
From: Daniel P. Berrange [mailto:berrange at redhat.com] 
Sent: Tuesday, December 09, 2014 4:04 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Nova][Neutron] out-of-tree plugin for Mech driver/L2 and vif_driver

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.

[IB] It should be up to the vendor to maintain it and make sure it's not broken. Having proper 3rd party CI in place should catch API contract changes.

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

[IB] This maybe the reasonable integration point. But it requires nova team review and approval. From my experience nova team is extremely overloaded, therefor getting this code reviewed become very difficult mission.
 
> 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.

[IB] I think that most of the vendors that maintain vif_driver out of nova, do not do it on purpose and would prefer to see it upstream. Sometimes host side binding is not fully integrated with libvirt and requires some temporary additional code, till libvirt provides complete support. Sometimes, it is just lack of nova team attention to the proposed spec/code  to be reviewed and accepted on time, which ends up with fully supported neutron part and missing small but critical vif_driver piece.
 
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 :|

_______________________________________________
OpenStack-dev mailing list
OpenStack-dev at lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev