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" <berra...@redhat.com> 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 :|
_______________________________________________ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
