Open Stack

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