On Wed, 2019-03-13 at 09:42 +0100, Erik Skultety wrote:
> The <source mode='bind'/> elements were added in commit 4d7ea75e and
> apparently generated by virt-install, but since the @path attribute
> is missing, the element will never be formatted back to the XML which the
> libvirt-go-xml-check expects, so it fails.
> The lack of the @path attribute is not a problem in general, because we
> can autogenerate the path in certain cases, so qemuxml2argvtest will
> always be happy, but XML formatting is a different thing.
>
> Therefore, drop these generated elements, as they're unnecessary for the
> purposes of qemuxml2argvtest and won't mess with the XML formatting
> test in Go.
>
> Signed-off-by: Erik Skultety <eskultet@xxxxxxxxxx>
> ---
>
> Additionally, I could introduce a xml2xml test here, but I already spent enough
> time hunting the CI failure down between libvirt and libvirt-go so this was the
> simplest solution which doesn't require any extra work.
I'm okay with the change, so
Reviewed-by: Andrea Bolognani <abologna@xxxxxxxxxx>
but I wonder if this is the expected behavior for the Go XML
parsing and formatting code?
IIUC from your description the test is basically parsing the input
file and formatting it back, and I would expect the process to be
either
* entirely dumb, so that each element and attribute that was
present in the input file will show up in the output file as
well; or
* as smart as libvirt's qemuxml2xmltest, which means the input
file will go through the whole postParse() rigmarole and come
out on the other side significantly altered.
It sounds like this test is mostly the former, but in this specific
case there is a little bit of logic sprinkled in? And somehow it
only affects the <source> element, because no other input file up
to this point caused issues?
CC'ing Dan who will certainly have some insights.
--
Andrea Bolognani / Red Hat / Virtualization
--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list
