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 :| _______________________________________________ OpenStack-dev mailing list OpenStackfirstname.lastname@example.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev