Open Stack

On Thu, Dec 11, 2014 at 04:15:00PM +0100, Maxime Leroy wrote:
> On Thu, Dec 11, 2014 at 11: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:
> >> >>
> >> >>
> [..]
> >> 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
> >
> 
> Having less VIF types, then using scripts to plug/unplug the vif in
> nova is a good idea. So, +1 for the idea.
> 
> If you want, I can propose a new spec for this. Do you think we have
> enough time to approve this new spec before the 18th December?
> 
> Anyway I think we still need to have a vif_driver plugin mechanism:
> For example, if your external l2/ml2 plugin needs a specific type of
> nic (i.e. a new method get_config to provide specific parameters to
> libvirt for the nic) that is not supported in the nova tree.

As I said above, there's a really small finite set of libvirt configs
we need to care about. We don't need to have a plugin system for that.
It is no real burden to support them in tree


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 :|