Re: [libvirt] [PATCH] schemas: Allow all generic elements and attributes for all interfaces

On 29.01.2015 11:25, Martin Kletzander wrote: > On Wed, Jan 28, 2015 at 06:23:08PM +0100, Michal Privoznik wrote: >> There are some interface types (notably 'server' and 'client') >> which instead of allowing the default set of elements and >> attributes (like the rest do), try to enumerate only the elements >> they know of. This way it's, however, easy to miss something. For >> instance, the <address/> element was not mentioned at all. This >> resulted in a strange behavior: when such interface was added >> into XML, the address was automatically generated by parsing >> code. Later, the formatted XML hasn't passed the RNG schema. This >> became more visible once we've turned on the XML validation on >> domain XML changes: appending an empty line at the end of >> formatted XML (to trick virsh think the XML had changed) made >> libvirt to refuse the very same XML it formatted. >> >> Instead of trying to find each element and attribute we are >> missing in the schema, lets just allow all the elements and >> attributes like we're doing that for the rest of types. It's no >> harm if the schema is wider than our parser allows. >> > > I'm pretty sure that separating it was the original intention, but > until it's separated properly without breaking things, I agree with > this fix. > >> Signed-off-by: Michal Privoznik <mprivozn(a)redhat.com&gt; >> --- >> docs/schemas/domaincommon.rng | 28 +--- >> .../qemuxml2argv-interface-server.xml | 157 >> +++++++++++++++++++++ > > So this file is added only for domainschematest? Why not check it by > xml2xml as well? Good point. > > This effectively allows interface-options to be used with any > interface, why not move it after the <choice/> element, so we're not > redundant? Not a good point. I mean, I don't think one is allowed to: <element> <interlave> <choice> <group/> <group/> <choice> </interleave> </element> simply because the choice groups may be defined by the value of an attribute to the top parent element. Well, at least if I did it that way I got an error from xmllint (and don't even get me started on it's error reporting capabilities. For a long while I thought we have the worst error reporting ever. Then I met xmllint).

> > ACK if you fix those two things. So I'm fixing the first issue and pushing. Thanks. Michal