Open Stack

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