[Libvir] generator.py -- why?

Daniel P. Berrange berrange at redhat.com
Tue Aug 29 11:11:46 UTC 2006


On Mon, Aug 28, 2006 at 11:53:09PM -0400, pvetere at redhat.com wrote:
> Hi all.  So, I found a bug in the python bindings that I'd really like to fix,
> but when I sat down to do so I quickly found myself mired in a swampy mess of
> code generation: generator.py.  :-)  Now, I feel compelled to ask -- why don't
> we just have a static libvirt.py file that is WYSIWYG?  The generator.py
> program alone is longer than the file it generates, and having a static file
> would not only make the code easier to read, but would also make bug fixing
> much simpler.  But, I'm sure there's got to be a good reason for it.  :-)
> 
> Here's a program that produces the bug I tried to address:
> 
> import libvirt
> def get_domain(dom_name):
>     conn = libvirt.openReadOnly(None)
>     domain = conn.lookupByName(dom_name)
>     return domain
> d = get_domain("mydomain")
> print d.info()
>
> This is a fairly typical "factory" pattern I could imagine people using.  The

This is a also a very bad pattern to use. Not only is opening a new connection
a fairly heavyweight opertion - it has to connect to xenstore, xend, and fork
fork the proxy server. Now if each time to your get_domain the domain object
returned is associated with a different connection object. This bypasseses the
caching of domain object instances which is done internal to libvirt, degrading
performance still further.

Regards,
Dan.
-- 
|=- Red Hat, Engineering, Emerging Technologies, Boston.  +1 978 392 2496 -=|
|=-           Perl modules: http://search.cpan.org/~danberr/              -=|
|=-               Projects: http://freshmeat.net/~danielpb/               -=|
|=-  GnuPG: 7D3B9505   F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505  -=| 




More information about the libvir-list mailing list