On Tue, Jan 14, 2014 at 01:11:38PM -0200, Eduardo Habkost wrote: > What was the reason to choose "e.output" for VMStartError and "e.reason" > for VMCreateError? If the "output" field existed on both classes, I > could simply catch both exceptions.
It's ad-hoc decision by who implemented the classes for the exceptions, but for VMCreateError the rationale is the result of running a command, so there is 'status' and 'output' attributes. And for VMStartError, it just 'reason' (no command execution). AFAIK there is no Python standard ruling this information for Exceptions. http://docs.python.org/2/tutorial/errors.html So since for is_defunct() I've choose to throw VMStartError, then the e.<something> becomes 'e.reason' (see virttest/virt_vm.py). For VMCreateError() you'll need e.output and so on, just because the class definition says so. IMO don't like the idea of using .output in both exceptions. Better to catch both Errors. > When I wrote the code above, VMStartError was raised and had all the > information I need. What I don't know is: was this change introduced on > purpose? I'm sorry for this inconvenience, but it was introduced to catch bugs that are happening when Qemu was defunct in the standard test suite (running without --tests option) on Fedora and others. So it makes sense for me to pick VMstartError (the process for qemu is alive). Maybe the order in qemu_vm.py code should change. > Why is it so important to differentiate alive=False,defunct=False from > alive=False,defunct=True? Why not just make is_alive() return False in > case the process is defunct? My answer is how is_alive() works, it verifies the process by looking for the files that the autotest framework create, for each process started. Where in is_defunct(), it walks in a process tree (no files) and grep for defunct. They are different approaches. I couldn't find a way to detect using is_alive() alone (this was my initial approach). > In my test case, I don't care at all if QEMU was defunct or not. QEMU > becoming defunct is not QEMU's fault: it is its parent's fault (in other > words, virt-test's fault for not wait()ing for it after it has > terminated). All I care about is catching cases when QEMU terminates, > and getting the stdout and stderr output when that happens. > But, is it really possible to have QEMU _not_ in defunct state if it is > not alive? In other words: is it possible to have both is_alive() and > is_defunct() returning False at the same time? If is_alive() is False, is_defunct() should returns False too. But my original problem is Qemu would be running (alive) but totally blocked for console interaction (defunct). Well, at least for black listed syscalls and sandbox on, this is possible. So is_defunct was born. > From the results I am seeing, it looks like virt-test is not wait()ing > QEMU when it aborts, and QEMU will always be in defunct state on those > cases. In this case, would you prefer to submit a new issue? > > That's why I am not sure yet if the new behavior is on purpose. If you > tell me the API won't change and I should look for VMCreateError, I will > happily change the test code. I don't think there is reason to change this API again. So I prefer that you happily change your test code; tell me if I can help you,I just need to setup something with RHEL. -- Ruda Moura _______________________________________________ Virt-test-devel mailing list [email protected] https://www.redhat.com/mailman/listinfo/virt-test-devel
