Open Stack

On 01/30/2013 02:26 PM, Daniel P. Berrange wrote:
> 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.

Isn't this particular issue being addressed in various parts of
OpenStack by using python entry points (via Doug Hellmann's stevedore
library) in place of class names?

I'm using stevedore in the Modular L2 (ml2) quantum plugin to load type
drivers and mechanism drivers. Configuration contains things like:

  type_drivers = flat,local,vlan

These names are then each resolved by stevedore in the
quantum.ml2.type_drivers entry point namespace to load and initialize an
instance of the desired class. The class names only appear in the
setup.py file(s) of the project(s) exporting the entry points. I believe
this allows the actual class name, or even where it comes from, to
change without breaking existing configurations. Administrators only
deal with the simple entry point names.

Applied here, a nova.firewall_driver namespace would contain entry
points mapping firewall driver names like "libvirt" to the classes. The
entry points are declared in the egg-info of the module, so both in-tree
and out-of-tree entry points are handled.

Obviously there is also an API contract for the drivers that needs to be
managed over time.

-Bob

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