Open Stack

Hi John and others, 

for my new neutron ml2 driver [3] I depend on a new vif_type in nova
being introduced [1]. I also added Sourabh to cc, as he probably tries
to achieve the same goal for another driver.


I'm also aware of the current discussion regarding vif-plug-script [2].
This approach only covers the plug/unplug methods that are required for
a new vif type, but not the generation of the domain.xml.


Now I have a couple of questions when it comes to new vif_types for
liberty:


- Is a spec required for a new vif type, or is it sufficient to propose
it via a bug? (This becomes important as next the spec freeze is some
time next week).


- I really rely on nova vif support for my new driver. Would it be ok to
get the get_config_<vif_type> method merged and for plug/unplug
operation jump on the boat of vif-plug-script [2]? To not break the code
I might add the plug/unplug methods for my driver as well, but would
just "pass" them. Any logic required would be added in the style of [2]
later on.


- The vif-plug-script spec [2] does not cover consolidation of the
xml-generating get_config_<vif_type> methods. Each vif_type still
requires it's own get_config_<vif_type> method. But some review comments
already point out, that it would make sense to once cover all libvirt
interface types in the vif driver. Once that's done and [2] is
implemented, vendor could use the new generic types instead of their own
types. Would you think it makes sense to set up an effort (bp + spec) to
evaluate what this would mean? If so I could start that, even if my
stuff gets merged tomorrow. 



Thanks a lot!


[1] https://review.openstack.org/#/c/182280/
[2] https://review.openstack.org/#/c/162468/
[3] https://review.openstack.org/#/c/189644/

-- 
Andreas
(IRC: scheuran)