Open Stack

On Dec 11, 2014, at 2:41 AM, Daniel P. Berrange <berrange at redhat.com> wrote:

> On Thu, Dec 11, 2014 at 09:37:31AM +0800, henry hly wrote:
>> 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.
> 
> Yes, I really think this is a key point. When we introduced the VIF type
> mechanism we never intended for there to be soo many different VIF types
> created. There is a very small, finite number of possible ways to configure
> the libvirt guest XML and it was intended that the VIF types pretty much
> mirror that. This would have given us about 8 distinct VIF type maximum.
> 
> I think the reason for the larger than expected number of VIF types, is
> that the drivers are being written to require some arbitrary tools to
> be invoked in the plug & unplug methods. It would really be better if
> those could be accomplished in the Neutron code than the Nova code, via
> a host agent run & provided by the Neutron mechanism.  This would let
> us have a very small number of VIF types and so avoid the entire problem
> that this thread is bringing up.
> 
> Failing that though, I could see a way to accomplish a similar thing
> without a Neutron launched agent. If one of the VIF type binding
> parameters were the name of a script, we could run that script on
> plug & unplug. So we'd have a finite number of VIF types, and each
> new Neutron mechanism would merely have to provide a script to invoke
> 
> eg consider the existing midonet & iovisor VIF types as an example.
> Both of them use the libvirt "ethernet" config, but have different
> things running in their plug methods. If we had a mechanism for
> associating a "plug script" with a vif type, we could use a single
> VIF type for both.
> 
> eg iovisor port binding info would contain
> 
>  vif_type=ethernet
>  vif_plug_script=/usr/bin/neutron-iovisor-vif-plug
> 
> while midonet would contain
> 
>  vif_type=ethernet
>  vif_plug_script=/usr/bin/neutron-midonet-vif-plug

+1 This is a great suggestion.

Vish

> 
> 
> And so you see implementing a new Neutron mechanism in this way would
> not require *any* changes in Nova whatsoever. The work would be entirely
> self-contained within the scope of Neutron. It is simply a packaging
> task to get the vif script installed on the compute hosts, so that Nova
> can execute it.
> 
> This is essentially providing a flexible VIF plugin system for Nova,
> without having to have it plug directly into the Nova codebase with
> the API & RPC stability constraints that implies.
> 
> Regards,
> Daniel
> -- 
> |: http://berrange.com      -o-    http://www.flickr.com/photos/dberrange/ :|
> |: http://libvirt.org              -o-             http://virt-manager.org :|
> |: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
> |: http://entangle-photo.org       -o-       http://live.gnome.org/gtk-vnc :|
> 
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 455 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20141211/8f71d11f/attachment.pgp>