Re: [Xen-devel] [XTF PATCH] xtf-runner: fix two synchronisation issues

[Andrew Cooper <andrew.cooper3@xxxxxxxxxx>]

On 29/07/16 13:58, Wei Liu wrote:
> On Fri, Jul 29, 2016 at 01:43:42PM +0100, Andrew Cooper wrote:
>> On 29/07/16 13:07, Wei Liu wrote:
>>> There were two synchronisation issues for the old code:
>>>
>>> 1. There was no guarantee that guest console was ready before "xl
>>>    console" invocation.
>>> 2. There was no guarantee that runner wouldn't not exit before all test
> s/not//
>
>>>    guests were gone.
>> Sorry, but I can't parse this.
>>
>> The runner existing before xl has torn down the guest is very
>> deliberate, because some part of hvm guests is terribly slow to tear
>> down; waiting synchronously for teardown tripled the wallclock time to
>> run a load of tests back-to-back.
>>
> Then you won't know if a guest is leaked or it is being slowly destroyed
> when a dead guest shows up in the snapshot of 'xl list'.
>
> Also consider that would make back-to-back tests that happen to have a
> guest that has the same name as the one in previous test fail.

test names are globally unique, so this isn't an issue.

Also, the wait for `xl console` to complete shows that @releasedomain
has been fired for the domain.

>
> I don't think getting blocked for a few more seconds is a big issue.
> It's is important to eliminate such race conditions so that osstest can
> work properly.

Amortising the teardown cost in the background is fine (which is what
your "for child in wait_list" ends up doing), but an extra few seconds
per test is very important to be avoided for manual use of XTF.

>>> +
>>> +        cmd = ['xenstore-read', '/local/domain/'+domid+'/name']
>>> +        print "Executing '%s'" % (" ".join(cmd), )
>>> +        gname = check_output(cmd).splitlines()[0]
>>> +        if gname != test: continue
>>> +
>>> +        cmd = ['xenstore-read', '/local/domain/'+domid+'/console/tty']
>>> +        print "Executing '%s'" % (" ".join(cmd), )
>>> +        con = check_output(cmd).splitlines()[0]
>>> +        if con != '': break
>> Somewhere in this loop, you should poll the call to xl create.  In the
>> case that there is an xl configuration error, this setup will wait for 5
>> seconds, then discard all trace of the error.
>>
> Right. I will see what I can do here.

Popen().poll() seems to do what you want.

~Andrew

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
https://lists.xen.org/xen-devel