On 8/1/19 6:30 AM, Eric Blake wrote:
On 7/31/19 4:58 PM, Daniel Henrique Barboza wrote:
> There is a chance that the current sed filtering used in
> these new tests might fail in some machines due to the
> repetition of the 'virsh #' prompt at the same line,
> together with valid output that shouldn't be filtered.
Ah, so it is a data race where the prompts produced by virsh don't
always flush in relation to other data being output.
Yes, eating all blank lines and just the prompt sub-string rather
than
the entire line with a prompt is a nice fix, and safe for freeze.
Actually, when I apply your patch, I run into failures on my end:
--- exp 2019-08-01 06:37:33.108617030 -0500
+++ out.cooked 2019-08-01 06:37:33.110617032 -0500
@@ -1,5 +1,11 @@
+ snapshot-create test --redefine s2.xml --validate
+ echo --err marker
+ # This is the right order
+ snapshot-create test --redefine s3.xml --validate
Domain snapshot s3 created from 's3.xml'
+ snapshot-create test --redefine s2.xml --current --validate
Domain snapshot s2 created from 's2.xml'
+ snapshot-info test --current
Name: s2
Domain: test
Current: yes
FAIL virsh-snapshot (exit status: 1)
So I think the difference is that your dev box is not echoing the
commands, and the real problem is that the test is dependent on the
current environment (is there some configuration file that determines
whether virsh in batch mode will echo what is typed?)
It would be possible to change the tests to use
virsh ... 'sequence of commands'
instead of
virsh ... <<EOF
sequence of commands
EOF
(in fact, that's what we do in the first half of the script); when you
do that, you no longer get the 'virsh #' prompts, nor any problem with
command echo. But before doing that, I'd still like to understand what
is different about your environment that suppresses the echo in the
first place, to encounter the output data race.
--
Eric Blake, Principal Software Engineer
Red Hat, Inc. +1-919-301-3226
Virtualization:
qemu.org |
libvirt.org