Hi Daniel,
Please see inline

-----Original Message-----
From: Daniel P. Berrange [mailto:berra...@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@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

Reply via email to