[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: [et-mgmt-tools] [patch 7/8] Add CapabilitiesParser module



On Wed, May 02, 2007 at 01:16:55PM +0100, Mark McLoughlin wrote:
> This adds a simple module for parsing libvirt's getCapabilities()
> XML.
> 
> It might seem more straightforward to just use XPath for this, but
> in the code to support arbitrary system images, you iterate over
> the various ways that the image can be booted and the various ways
> in which a hypervisor can boot a guest and find the best match. For
> that kind of use, the API below is much easier to use.
> 
> Note, this parser rejects things like architectures it doesn't
> know about, which needs to be fixed in order to have forward
> compatibility.

I really don't like this. If we were using these APIs to construct
new XML capabilities info I'd agree on the validation. In this case
though we are merely using the APIs to keep an in-memory representation
of data we parsed from libvirt. We should be trusting that data, since
the prime reason for the capabilities info in the first place to was
have a source apps could use & thus not have to hardcode anything in
the apps themselves.  

> +class Host(object):
> +    ARCHES = [ "i686", "x86_64" ]

ia64 & ppc guys will come after you with pitch forks :-)

> +class Guest(object):
> +    OS_TYPES = [ "xen", "hvm" ]
> +    HYPERVISOR_TYPES = [ "xen", "qemu", "kqemu", "kvm" ]
> +    ARCHES = [ "i686", "x86_64", "mips", "mipsel", "sparc", "ppc" ]

Again, I don't think we should be doing this kind of white listing
here. If an application using the 'Guest' object only supports a
certain subset, it can whitelist, but this object should jst be a
pure representation of everything libvirt gives us in the XML.

> +    try:
> +        #
> +        # FIXME: when we can rely on python-2.5 and its support for
> +        #        try ... except ... finally, remove this inner try

Never ! Or to put it another way - how many years before Debian ends up 
with python 2.5. I think 2.4 needs to be supported pretty much indefinitely

> +if __name__ == "__main__":
> +    import libvirt
> +
> +    for uri in (None, "qemu:///system"):
> +        cnx = libvirt.open(uri)
> +
> +        caps = parse(cnx.getCapabilities())
> +
> +        print "host arch: %s" % caps.host.arch
> +        if caps.host.features:
> +            print "host features:"
> +            for feature in features_map:
> +                if caps.host.features & features_map[feature]:
> +                    print "    " + feature
> +
> +        for guest in caps.guests:
> +            print
> +            print "guest arch: %s" % guest.arch
> +            print "guest os type: %s" % guest.os_type
> +            print "guest hypervisor type: %s" % guest.hypervisor_type
> +            if guest.features:
> +                print "guest features:"
> +                for feature in features_map:
> +                    if guest.features & features_map[feature]:
> +                        print "    " + feature
> +
> +        print

We have a formal test suite in virtinst for checking correctness. Could
we have something added to tests/ to do sanity checking of the parsing
routines.

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


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]