11:09 a.m.
On 12/10/2009 10:51 AM, Diego Elio “Flameeyes” Pettenò wrote:
Hello,
In a recent post on my blog [1] I ranted on about libvirt and in
particular I complained that the configuration files look like what I
call “almost XML�. The reasons why I say that are multiple, let me try
to explain some.
In the configuration files, at least those created by virt-manager there
is no specification of what the file should be (no document type, no
namespace, and, IMHO, a too generic root element name); given that some
kind of distinction is needed for software like Emacs's nxml-mode to
know how to deal with the file, I think that's pretty bad for
interaction between different applications. While libvirt knows
perfectly well what it's dealing with, other packages might not. Might
not sound a major issue but it starts tickling my senses when this
happens.
The configuration seem somewhat contrived in places like the disk
configuration: if the disk is file-backed it require the file attribute
to the <source> element, while it needs the dev attribute if it's a
block device; given that it's a path in both cases it would have sounded
easier on the user if a single path attribute was used. But this is
opinable.
This is something that has always bugged me as well, and is indeed a
pain to deal with in virt-manager when doing things like changing cdrom
media. I think we should just loosen the input restrictions, so that any
path passed via the <source> properties file, dev, or dir are used, but
will be dumped with the 'correct' property to maintain back compat.
That said, I think the XML format is pretty straight forward. The above
caveat you mention is the only real annoying thing. The one other
stumbling block is that not all devices have a unique property to key
off of in the XML (ex. you can have two identical <video> devices). This
makes life difficult for virt-manager when removing a device, but it
hasn't been a big issue in practice.
The third problem I called out for in the block is a lack of a
schema
for the files; Daniel corrected me pointing out that the schemas are
distributed with the sources and installed. Sure thing, I was wrong. On
the other hand I maintain that there are problems with those schemas.
The first is that both the version distributed with 0.7.4 and the git
version as of today suffer from bug #546254 [2] (secret.rng being not
well formed) so it means nobody has even tested them as of lately; then
there is the fact that they are never referenced by the human-readable
documentation [3] which is why I didn't find it the first time around;
add also to that some contrived syntax in those schema as well that
causes trang to produce a non-valid rnc file out of them (nxml-mode uses
rnc rather than rng).
The bug you mention only exists because we don't have secret XML
regression tests. Other schemas are in better shape: I'm pretty
confident that virtual network and storage pool/volume schemas have near
complete coverage. Domain probably has very high coverage but there are
no doubt nuances of the format that aren't covered by our regression
suite, and therefor may have incorrect schemas.
For a long while we didn't use the XML schemas for anything so they were
horrendously out of date and practically useless. That has changed
within the past year but we are still playing catchup to have the schema
match libvirt code reality.
Putting a link to schemas on the website is also a good idea.
But I guess the one big problem with the schemas is that they
don't seem
to properly encode what the human-readable documentation says, or what
virt-manager does. For instance (please follow me with selector-like
syntax), virt-manager creates /domain/os/type[(a)machine='pc-0.11'] in the
created XML; the same attribute seem to be documented: “There are also
two optional attributes, arch specifying the CPU architecture to
virtualization, and machine referring to the machine type�. The schema
does not seem to accept that attribute though (“element type: Relax-NG
validity error : Invalid attribute machine for element type� with
xmllint, just to make sure that it's not a bug in any other piece of
software, this is Daniel's libxml2).
If there are any other pieces of the schema that you find are incorrect
or don't match reality, please enumerate them here and I'll take some
time to make sure they are tested in our regression suite.
Thanks,
Cole