Upstream,
Some ideas have been floating around about combining the various
"virtualization" testing all under one set of "virt" subdirectories.
If we do head down this road, the question of organization comes to
mind. What are some ways the virtualization trees could be organized?
-----
My idea: Organize based on dependencies, least-to-most specific-
e.g. autotest/client/tests/virt/qemu-kvm/libvirt/Fedora/nic_bonding.py
<top-level>/<host-level>/<engine-level>/<guest-level>/<test-level>
top-level:
autotest/client/virt:
general-use classes, resources, & abstractions
autotest/client/tests/virt:
specialized resources, configurations, & tests
host-level:
guest image pool:
file directory, lvm, iscsi, etc.
build pool:
install iso directory, nfs, yum repo, etc.
scripts, deps, lib:
prep, cleanup, ext. utilities, etc.
engine-level:
direct:
direct to hypervisor
libvirt:
use python bindings
virt-utils:
use libvirt utils virt-install, virsh
hyper-v:
windows stuff
guest-level:
hardware:
virtual hardware resources & configurations
software:
guest operating-system resources, configurations
resources:
kickstarts, answer files, cd keys, address lists, etc.
test-level:
guest internal,
benchmarks,
profilers,
etc.
-----
But maybe there's another order/sequence that makes more sense. What's
your ideas for structure, layout, or layer-logic?
Thanks.
--
Chris Evich, RHCA, RHCE, RHCDS, RHCSS
Quality Assurance Engineer
e-mail: cevich + `@' + redhat.com o: 1-888-RED-HAT1 x44214
_______________________________________________
Autotest mailing list
[email protected]
http://test.kernel.org/cgi-bin/mailman/listinfo/autotest
