Hi there. I would like some clarification regarding support of out-of-tree plugin in nova and in neutron.
First, on neutron side, there are mechanisms to support out-of-tree plugin for L2 plugin (core_plugin) and ML2 mech driver (stevedore/entrypoint). Most of ML2/L2 plugins need to have a specific vif driver. As the vif_driver configuration option in nova has been removed of Juno, it's not possible to have anymore external Mech driver/L2 plugin. The nova community takes the decision to stop supporting VIF driver classes as a public extension point. (ref http://lists.openstack.org/pipermail/openstack-dev/2014-August/043174.html) At the opposite, the neutron community still continues to support external L2/ML2 mechdriver plugin. And more, the decision to put out-of-the-tree the monolithic plugins and ML2 Mechanism Drivers has been taken in the Paris summit (ref https://review.openstack.org/#/c/134680/15/specs/kilo/core-vendor-decomposition.rst) I am feeling a bit confused about these two opposite decisions of the two communities. What am I missing ? 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 ? 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 ? What other reasons am I missing to not have VIF driver classes as a public extension point ? Thanks in advance for your help. Maxime _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
