On 8/30/2014 11:22 PM, Ian Wells wrote:
The problem here is that you've removed the vif_driver option and now you're preventing the inclusion of named VIF types into the generic driver, which means that rather than adding a package to an installation to add support for a VIF driver it's now necessary to change the Nova code (and repackage it, or - ew - patch it in place after installation). I understand where you're coming from but unfortunately the two changes together make things very awkward. Granted that vif_driver needed to go away - it was the wrong level of code and the actual value was coming from the wrong place anyway (nova config and not Neutron) - but it's been removed without a suitable substitute.

It's a little late for a feature for Juno, but I think we need to write something discovers VIF types installed on the system. That way you can add a new VIF type to Nova by deploying a package (and perhaps naming it in config as an available selection to offer to Neutron) *without* changing the Nova tree itself.

In the meantime, I recommend you consult with the Neutron cores and see if you can make an exception for the VHOSTUSER driver for the current timescale.
--
Ian.

I Agree with Ian.
My understanding from a conversation a month ago was that there would be an alternative to the deprecated config option. As far as I understand now there is no such alternative in Juno and in case that one has an out of the tree VIF Driver he'll be left out with a broken solution.
What do you say about an option of reverting the change?
Anyway It might be a good idea to discuss propositions to address this issue towards Kilo summit.

BR,
Itzik

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

Reply via email to