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

Re: [libvirt] ignore vs. error when inappropriate or unrecognized attributes/elements are present in XML

On 08/16/2011 11:47 AM, Daniel P. Berrange wrote:
On Tue, Aug 16, 2011 at 04:44:42AM -0400, Laine Stump wrote:
This is related to: https://bugzilla.redhat.com/show_bug.cgi?id=638633#c14

I had started to reply to it in the comments of the bug, but my
reply became too long, and expanded into an issue wider than that
single bug, so I figured I'd better discuss it here instead.

Actually, I can see now there are several different classes of this
problem. Here are the first few that come to mind:

1) an attribute/element is completely unknown/unexpected in all
cases (e.g. "frozzle='fib'" anywhere, or more insidious, something
that *looks* correct, but isn't, e.g. "<script
RNG schema validation is the only sane way to catch this


2) an attribute/element is useful/expected only when some other
attribute is set to a particular value (usually one called "type",
but could be something else), for example keymap='blah' is only
expected in a<graphics>  element when type='spice' or type='vnc'.
We should always catch these when parsing, since this is done
via our enumeration helpers.

"Enumeration helpers"? My brain isn't making the connection to what you're talking about... :-)

3) an attribute/element is useful/expected only for certain
combinations of the value of some other attribute and which driver
is using the element, e.g. the subject of this bug - script='blah'
is only expected when type='bridge' and it's used by the Xen driver,
or type='ethernet' and it's used by the qemu driver.
IMHO this is just another case of 1) really.

I guess as long as the hypervisor being used is part of the XML, and the RNG is detailed enough to note that, eg, when the hypervisor is xen and the interface type is bridge, a script element is okay, or when the hypervisor is qemu and the interface type is ethernet, a script is okay, but not in other cases. Wouldn't an RNG file that adequately described that be fairly gigantic and filled with redundancies, though?

So what are the rules of engagement for these various cases? When do
we ignore, when do we log an error during parsing, and when do we
log an error in the code that's using the parsed data?
I think we should add a flag to 'virDomainDefine' and virDomainCreateXML


and when that is set, run the user specified XML through the
RNG schema validator. Virsh could be extended to have a --validate
flag too.

We'd add an explicit error code  VIR_ERROR_XML_VALIDATION to let
apps catch schema failures.

This would fix a major annoyance with 'virsh edit' where you make
XML changes and they get lost because you typod.  ie virsh edit
sets the validate flag. If it gets a failure it should ask the user
whether they want to abandon the edit, force the edit (ie define without
the validate flag), or re-launch the editor to correct the mistake.

If we did this we'd get much more use of the RNG schemas and so
find mistakes in them sooner

+10 I like it!

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