Re: [Libvirt-cim] [PATCH] REDSAP: Fix double exception possibilty

On 09/06/2013 03:46 PM, John Ferlan wrote: > Test failed with the following: > > -------------------------------------------------------------------- > KVMRedirectionSAP - 01_enum_KVMredSAP.py: FAIL > ERROR - Failed to enumerate the class of KVM_KVMRedirectionSAP > ERROR - Exception details: Got more than one record for: > test_kvmredsap_dom > ERROR - Exception details: 'ElementName' Value Mismatch, > Expected 5988:-1, Got 5988:0 > ERROR - Exception: Failed to verify information for the > defined dom:test_kvmredsap_dom > -------------------------------------------------------------------- > > There are two exceptions listed because the 'enum_redsap()' method was > perusing a list, finding a match, declaring success, and continuing to > peruse the list. Then found another match declared an exception and > returned > with status = PASS. > > The caller just checked the status before continuing. > > This patch doesn't resolve the underlying cause, but does avoid the > call to > 'verify_redsap_values()' which will also fail... > --- > > NOTE: I was able to reproduce the initial exception if I run this test > very quickly two times in succession. I debated adding a 'sleep(5)' (or > similar) prior to the end of the test to ensure whatever teardown was > not occurring in a timely manner (by the networking code) could happen, > but I believe that wouldn't necessarily fix the problem - just make it > less likely to happen. The resource in question is a specific port in the > underlying VNC technology. That code may have built in 'safeguards' to > help > with throttling, e.g. reuse a recently used port thus make it > unreliable for > the test to rely on getting the "first" port. Since the test isn't > designed > to run twice in a row, I don't think it's a real issue... > > .../libvirt-cim/cimtest/KVMRedirectionSAP/01_enum_KVMredSAP.py | 9 > ++++----- > 1 file changed, 4 insertions(+), 5 deletions(-) > The patch fixes the previously incorrect error handling, so I would suggest to push it anyway. The failure doesn't seem to happen because of a lingering socket but rather becasue the guest wasn't destroyed and/or undefined (returned port is 0). Did this failure ever reoccur *after* you have applied your change?