Login | Register For Free | Help
Search for: (Advanced)

Mailing List Archive: OpenStack: Dev

questions on the dynamic loading of virt drivers in nova

 

 

OpenStack dev RSS feed   Index | Next | Previous | View Threaded


sdague at linux

May 9, 2012, 1:32 PM

Post #1 of 3 (122 views)
Permalink
questions on the dynamic loading of virt drivers in nova

I'm familiarizing myself with the nova code and trying to reconcile that
while there is dynamic class based loading in ComputeManager using
import_utils in __init__() there is also a defaulting to the
nova.virt.connection.get_connection function.

That's actually got a big if / else statement of string literals of
known virt drivers, and then loads specific virt drivers from there.

Is there a reason for both approaches? Can we refactor to a point where
we don't need need of a common file with driver specific imports and
string literals? Is there a reason not to?

Thanks,

-Sean

--
Sean Dague
IBM Linux Technology Center
email: sdague [at] linux
alt-email: sldague [at] us


_______________________________________________
Mailing list: https://launchpad.net/~openstack
Post to : openstack [at] lists
Unsubscribe : https://launchpad.net/~openstack
More help : https://help.launchpad.net/ListHelp


vishvananda at gmail

May 9, 2012, 5:13 PM

Post #2 of 3 (114 views)
Permalink
Re: questions on the dynamic loading of virt drivers in nova [In reply to]

No this is mostly just legacy stuff that was never refactored.

Vish
On May 9, 2012 3:33 PM, "Sean Dague" <sdague [at] linux> wrote:

> I'm familiarizing myself with the nova code and trying to reconcile that
> while there is dynamic class based loading in ComputeManager using
> import_utils in __init__() there is also a defaulting to the
> nova.virt.connection.get_**connection function.
>
> That's actually got a big if / else statement of string literals of known
> virt drivers, and then loads specific virt drivers from there.
>
> Is there a reason for both approaches? Can we refactor to a point where we
> don't need need of a common file with driver specific imports and string
> literals? Is there a reason not to?
>
> Thanks,
>
> -Sean
>
> --
> Sean Dague
> IBM Linux Technology Center
> email: sdague [at] linux
> alt-email: sldague [at] us
>
>
> ______________________________**_________________
> Mailing list: https://launchpad.net/~**openstack<https://launchpad.net/~openstack>
> Post to : openstack [at] lists
> Unsubscribe : https://launchpad.net/~**openstack<https://launchpad.net/~openstack>
> More help : https://help.launchpad.net/**ListHelp<https://help.launchpad.net/ListHelp>
>


thierry at openstack

May 10, 2012, 10:29 AM

Post #3 of 3 (113 views)
Permalink
Re: questions on the dynamic loading of virt drivers in nova [In reply to]

You might want to talk to Soren and fix it within:

https://blueprints.launchpad.net/nova/+spec/hypervisor-code-consolidation

since this will also result in refactoring in the same area.

Vishvananda Ishaya wrote:
> No this is mostly just legacy stuff that was never refactored.
>
> Vish
>
> On May 9, 2012 3:33 PM, "Sean Dague" <sdague [at] linux
> <mailto:sdague [at] linux>> wrote:
>
> I'm familiarizing myself with the nova code and trying to reconcile
> that while there is dynamic class based loading in ComputeManager
> using import_utils in __init__() there is also a defaulting to the
> nova.virt.connection.get_ connection function.
>
> That's actually got a big if / else statement of string literals of
> known virt drivers, and then loads specific virt drivers from there.
>
> Is there a reason for both approaches? Can we refactor to a point
> where we don't need need of a common file with driver specific
> imports and string literals? Is there a reason not to?
>
> Thanks,
>
> -Sean
>
> --
> Sean Dague
> IBM Linux Technology Center
> email: sdague [at] linux <mailto:sdague [at] linux>
> alt-email: sldague [at] us <mailto:sldague [at] us>
>
>
> ______________________________ _________________
> Mailing list: https://launchpad.net/~ openstack
> <https://launchpad.net/~openstack>
> Post to : openstack [at] lists
> <mailto:openstack [at] lists>
> Unsubscribe : https://launchpad.net/~ openstack
> <https://launchpad.net/~openstack>
> More help : https://help.launchpad.net/ ListHelp
> <https://help.launchpad.net/ListHelp>
>
>
>
> _______________________________________________
> Mailing list: https://launchpad.net/~openstack
> Post to : openstack [at] lists
> Unsubscribe : https://launchpad.net/~openstack
> More help : https://help.launchpad.net/ListHelp


--
Thierry Carrez (ttx)
Release Manager, OpenStack

_______________________________________________
Mailing list: https://launchpad.net/~openstack
Post to : openstack [at] lists
Unsubscribe : https://launchpad.net/~openstack
More help : https://help.launchpad.net/ListHelp

OpenStack dev RSS feed   Index | Next | Previous | View Threaded
 
 


Interested in having your list archived? Contact Gossamer Threads
 
  Web Applications & Managed Hosting Powered by Gossamer Threads Inc.