[libvirt] [test-API] RFC: Stabilization of libvirt-test-API

Hi everyone, following our minutes, I'd like to start a discussion on what should be done with libvirt-test-API so we can say it's stable and usable. I would like to stress out that everything mentioned here is just an opinion and I don't mean to talk down to someone as it may have seemed earlier. I think we should get some ideas from everyone, mostly QE as they will be (are) the ones using this the most (if I understood correctly), and then I'll be happy to help getting the code to the agreed status. I was thinking about this from the wrong way probably and changing the angle from what I look at it (and knowing there is some deadline) makes me think of few levels of changes, which when introduced, could speed up the test development and code understandability. So here are the things I would like to do definitely (the optional things follow later on): - fix hard-coded options into real options (e.g. commit 65449e) - fix some env_* and util* code (functions duplicated with different behavior) - fix or remove harmful and pointless code (at this point, when creating domain on remote machine, be prepared for the test to fail with any other user then root and with root, have backup of both local and remote '/root/.ssh' directories as the contents will be erased!) - fix method names for the {connect,domain,etc.}API (get_host_name vs. lookupByUUID etc.) The optional things: - get rid of classes in lib and make just few utility functions covering *only* the methods that do something else than call the same method in underlying class from the libvirt module. - get rid of the new exception (I don't see any other difference than in the name, which can make a difference in "except:" clause, but it's converted everywhere) - be able to share variables between tests (connection object and anything else) - introduce new config file for tests (.ini format, can be parsed by ConfigParser, same as env.cfg, define variables used throughout the test specifications - update the documentation - use some python code style (PEP-8?), make use of True/False, None - eliminate duplicated (and x-plicated) code (append_path in all the files, etc.) I have all of these figured out, so I'm willing to discuss all of them, but in most cases changing it in the current code seems very time-consumable to me. Please, feel free to comment on any of these, add yours, discuss, shout at me, etc. =) Regards, Martin P.S.: I don't see any point in sending my patches until some of these points are resolved as that could mean rewriting more code.