On Wed, Nov 25, 2020 at 12:44 AM Peter Krempa <pkrempa@redhat.com> wrote:

On Tue, Nov 24, 2020 at 15:25:01 -0600, Dustan B Helm wrote:
> On Tue, Nov 24, 2020 at 12:59 AM Peter Krempa <pkrempa@redhat.com> wrote:
> > On Mon, Nov 23, 2020 at 17:17:15 -0600, Dustan B Helm wrote:

[...]

- any XML addition requires tests to be added

In this case you'll be also needing to add a qemu commandline test
later so I suggest you add your XML test as a new file to:
tests/qemuxml2argvdata, and enable the test in
tests/qemuxml2xmltest.c (output file is stored in
tests/qemuxml2xmloutdata, you can also run the test with
VIR_TEST_REGENREATE_OUTPUT=1 env variable set which generates the
proper output file)

Always use one of the _CAPS_LATEST macros for invoking the test
regardless of prior art.

You can add multiple disks to the tested XML to test any combination
of the <nfs> parameters.

Please make sure to list at least one example of the NFS disk being
a <backingStore> of a <source>
(see tests/qemuxml2argvdata/disk-backing-chains.xml for inspiration)

Don't forget to also document the new elements in
docs/formatdomain.rst

We don’t understand exactly how the testing frameworks are functioning. With regards to our XML testing, the tests/qemuxml2argvdata/ directory contains for each test both an xml file and an args file- is this .args file the expected output qemu command we want to generate from the input .xml file?

If so, how do we invoke the VIR_TEST_REGENERATE_OUTPUT flag to create this .args file, and how concerned should we be about non-disk information provided in the .xml file as input? Additionally, since our source name (a file path) needs to include the NFS export at the beginning, how would we set up the XML input? Can the file path and NFS export be chosen arbitrarily?