Open Stack

On Wed, Jan 30, 2013 at 10:25:07AM -0800, Dan Wendlandt wrote:
> On Tue, Jan 29, 2013 at 4:30 AM, Daniel P. Berrange <berrange at redhat.com>wrote:
> > So I don't want to have anything where we magically ignore the
> > 'libvirt_vif_driver' parameter in some scenarios - we should always
> > honour that parameter. Just that with it configured to
> > LibvirtGenericVIFDriver,
> > 99% of users will never need to touch it now.
> >
> 
> Yeah, I agree on the goal of having the LibvirtGenericVIFDriver as the
> default behavior, I'm must less convinced that in the long-term we'd even
> want to keep the vif-driver stuff around at all.  Having Quantum
> automatically use the generic vif-driver behavior if the vif-plugging
> extension is in use seems to provide a smoother transition, and a cleaner
> and more simple system in the end.

This debate is getting into a bit more of a philosophical position
on what level of code extension we allow for. From what I see the
general OpenStack policy seems to be to allow extensions all over
the codebase, by letting the user specify arbitrary classnames.
Now personally I think this is a mistake because as you say, in
practice out of tree code tends to be already broken, or at risk
of being broken at every OpenStack release, or downright buggy.
I also think classnames are a really horrible to thing to ask
admins to deal with from a usability POV. They also force us to
needlessly break user configs at upgrades. For example if we want
to rename a class, we break the user config since it is hooking
on classname which ought to be a hidden internal impl detail.

If I was an admin wanting to configure Nova to use libvirt and
had a choice between setting 

  firewall_driver = "nova.virt.libvirt.firewall.IptablesFirewallDriver"

or just

 firewall_driver = "libvirt"

IMHO there's no contest & it would avoid us breaking user configs
nearly so often.

So I'm totally with you on the desire to eliminate things like the
vif_driver config parameter, and many more similar config parameters
besides. I loathe to do that as part of this work though, because it
feels more like we need to put some general project-wide thought into
the question of what level of out-of-tree extensibility we want to
allow for.

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