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

Martin Kletzander mkletzan at redhat.com
Thu Jan 29 10:25:15 UTC 2015


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 at redhat.com>
>---
> 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?

This effectively allows interface-options to be used with any
interface, why not move it after the <choice/> element, so we're not
redundant?

ACK if you fix those two things.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/libvir-list/attachments/20150129/41660591/attachment-0001.sig>


More information about the libvir-list mailing list