Open Stack

On Thu, Dec 11, 2014 at 3:48 AM, Ian Wells <ijw.ubuntu at cack.org.uk> wrote:
> On 10 December 2014 at 01:31, Daniel P. Berrange <berrange at redhat.com>
> wrote:
>>
>>
>> So the problem of Nova review bandwidth is a constant problem across all
>> areas of the code. We need to solve this problem for the team as a whole
>> in a much broader fashion than just for people writing VIF drivers. The
>> VIF drivers are really small pieces of code that should be straightforward
>> to review & get merged in any release cycle in which they are proposed.
>> I think we need to make sure that we focus our energy on doing this and
>> not ignoring the problem by breaking stuff off out of tree.
>
>
> The problem is that we effectively prevent running an out of tree Neutron
> driver (which *is* perfectly legitimate) if it uses a VIF plugging mechanism
> that isn't in Nova, as we can't use out of tree code and we won't accept in
> code ones for out of tree drivers.

The question is, do we really need such flexibility for so many nova vif types?

I also think that VIF_TYPE_TAP and VIF_TYPE_VHOSTUSER is good example,
nova shouldn't known too much details about switch backend, it should
only care about the VIF itself, how the VIF is plugged to switch
belongs to Neutron half.

However I'm not saying to move existing vif driver out, those open
backend have been used widely. But from now on the tap and vhostuser
mode should be encouraged: one common vif driver to many long-tail
backend.

Best Regards,
Henry

> This will get more confusing as *all* of
> the Neutron drivers and plugins move out of the tree, as that constraint
> becomes essentially arbitrary.
>
> Your issue is one of testing.  Is there any way we could set up a better
> testing framework for VIF drivers where Nova interacts with something to
> test the plugging mechanism actually passes traffic?  I don't believe
> there's any specific limitation on it being *Neutron* that uses the plugging
> interaction.
> --
> Ian.
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>