openstack team mailing list archive

[Joshua Harlow <harlowja@xxxxxxxxxxxxx>]

Cool,

Maybe I can get a branch out there that u can start hooking in by early feb.

That would seem like a good use of time :-)

On 1/6/12 3:21 AM, "Daniel P. Berrange" <berrange@xxxxxxxxxx> wrote:

On Thu, Jan 05, 2012 at 10:33:00AM -0800, Joshua Harlow wrote:
> Hmmm, so the RNG schemas aren't stable? Is that basically
> the problem there (or part of it)? That seems not so good,
> since I thought the whole point of publishing schemas was
> for people to use them, darn :(

Well there are two different things here to be considered:

 1. The XML document described by the schema
 2. The XML schema itself

Item 1 is long term stable, item 2 is not stable.

> This libvirt-gconfig does sound good though, is there anyway
> we can get the dependencies relaxed to versions that other
> distributions can actually handle (without having more
> dependencies that need to be custom built). Is there a need
> for the glib dependency to be that recent (or is the gobject
> introspection-stuff just that new?).

Unfortunately the only way would be to custom compile a new
glib + gobject introspection stuff for old distros. While the
introspection stuff has been in development for a year or two,
it was only declared stable at approx the same time GNOME 3
was released.

> Still though I think what the above does is still just provide the lower level or the idea I was thinking:
>
> The three levels were:
>
>
>  1.  Object format that contains methods/properties for exactly what we use with libvirt
>     *   Not connected to #2 or #3 in any way
>  2.  Formatter layer that takes in #1 and outputs a string/file (or something similar) using various #3 lower level formats
>     *   One formatter could be a TempitaLibvirtFormatter
>     *   Second could be RngLibvirtFormatter (or GconfigLibvirtFormatter when that happens...)
>  3.  Lower level objects/libraries
>     *   This would be where RNG->python objects would live or the libvirt-gconfig objects
>     *   This could also use a tempita library
>
> Right now basically there is libvirt/connection.py which
> interacts with #3 (tempita), instead of interacting with #1.
> So this could be phased, get #1, #2, #3 working with the current
> stuff (actually a simplified tempita since I really want to get
> rid of the usage of tempita as a mini-scripting language, since
> the last time I checked we are in python to begin with). #3 could
> then use this simplified tempita template, until this libvirt-gconfig
> comes along (is there a timeline for that?).
>
> Thoughts?

This sounds like a good abstraction idea, since it is cleanly separating
out domain configuration from the LibvirtConnection class. So IIUC, the
'to_xml' method in LibvirtConnection would get an instance of the
abstract LibvirtDomainFormatter class, and call a to_xml() like method
on that todo the formatting. We could start with a simple subclass called
LibvirtTempitaDomaiNFormatter which just contains the current code from
_prepare_xml_info. Then in the future we would then introduce new subclasses
like LibvirtGConfigDomainFormatter, or whatever else we like.

WRT to libvirt-gconfig, my intention was to start experimenting on an
Nova impl using that towards the end of January / early Feb.

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