Google
  Web www.spinics.net

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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]


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.

--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list


[Virt Tools]     [Libvirt Users]     [Fedora Users]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [Fedora SELinux]     [Big List of Linux Books]     [Yosemite News]     [Yosemite Photos]     [KDE Users]     [Fedora Tools]

Powered by Linux

Google
  Web www.spinics.net