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
