On 12/24/2010 11:45 AM, Lucas Meneghel Rodrigues wrote: > Hi folks, > > I am here planning our activities for the next year, and our big task > for the 1st quarter of the year is the KVM autotest refactor, to > accomodate other hypervisor's testing. > > Eduardo sent a patchset creating a KVM package inside the kvm test > directory. After some discussion with Michael, we think it is better to > create the package, but on its more long-term location, > autotest_lib.client.bin. So, my proposition is:
+1 > Libraries that can be used by all client side tests > > KVM configuration: The kvm config class can be moved to > autotest_lib.client.bin.test_config, with a new class name > ConfigCartesian. > > from autotest_lib.client.bin import test_config > > KVM subprocess: That can be moved to a new > autotest_lib.client.bin.subprocess module. I would like to move all > autotest APIs to control subprocess in there, such as the current > utils.run, utils.system and friends. > > from autotest_lib.client.bin import subprocess > > Libraries that can be used by virtualization testing in general > > We can create a package autotest_lib.client.bin.virt, with the following > libraries: > > KVM monitor: > > from autotest_lib.client.bin.virt import monitor > > KVM environment class: > > from autotest_lib.client.bin.virt import env > > KVM postprocessing module: > > from autotest_lib.client.bin.virt import env_processing > > KVM scheduler: > > from autotest_lib.client.bin.virt import scheduler > > KVM utils: > > from autotest_lib.client.bin.virt import utils > > KVM test utils: > > from autotest_lib.client.bin.virt import test_utils > > KVM vm class: > > from autotest_lib.client.bin.virt import vm > > KVM rss file transfer: > > from autotest_lib.client.bin.virt import rss_client > > I am a bit reluctant to write patches before I have some level of > feedback on it, so please let me know what you think. > I also feel it's important to have a clear plan and policy about writing and committing patches on both kvm libraries and kvm tests during this process. My suggestion is that we set a date to freeze all changes in current kvm libraries, and after that focus solely on new common library code. We could allow urgent and critical changes to kvm libraries if the patch *also* deals with code under the common library namespace. Naturally, the next step would be to migrate the kvm tests, making them use the new common library. This would also be an apportunity to have ported tests from xen-autotest to validate the design. Only after every single tests has been migrated, we'd then drop the current (then old) kvm libraries. This way, we'd allow for current tests to keep using the current (then old) kvm libraries. CR. > Cheers, > > Lucas > _______________________________________________ Autotest mailing list [email protected] http://test.kernel.org/cgi-bin/mailman/listinfo/autotest
