On Thu, Jan 13, 2011 at 11:11 AM, Tommi Virtanen <[email protected]> wrote:
> Hi. We're trying to use Autotest for the Ceph cluster filesystem > (http://ceph.newdream.net/) and are running out of good examples. > > Say we have two kinds of machines: 4U beefy servers to use as storage > nodes, and 1U machines that are just fast enough to act as clients. > We'd want to run tests that need e.g. 1 server and 2 client machines > to complete. Or 7 servers and 20 clients. > Even better would be to have Autotest understand which machines are in > which rack/row, so we could have the test network traffic never > traverse between two rows in the data center -- we don't want the > central switches to be the bottleneck. > > We've got a lot of tests internally that are similar to this. Run some servers somewhere and drive a much larger set of load generators against those servers. To keep things from crossing boundaries, we label each group of hosts appropriate for one of these tests with a label specific to that purpose. (foo_loadtest_rack1, foo_loadtest_rack2, etc). This can be an atomic group label but use of atomic groups for this is often overkill unless you need to deal with frequently losing one or two machines and still being able to run the test with "at least N from this group" rather than "exactly these N." ACLs and atomic groups are quite often overkill. a "metahost" is really just another term for "host label": % atest job create -b foo_loadtest_rack1 -s -t foo_loadtest ... schedules a job to run on foo_loadtest_rack1. etc.. All of that assumes you are actually running and using the autotest scheduler and not just autoserv manually. I'm looking at ACLs, metahosts, atomic groups, host_group_name, > --execution-tag= but just can't figure out if something already allows > me to do this. Right now ACLs seem the most promising approach.. > > Worst case, I write my own resource allocation, call autoserv with a > pre-picked -m argument, and use extra knowledge about hostnames to > decide what machine does what. > Yes, we always ended up with the server side test itself having to look at the list of machines it was given and make decisions based on those as to what parts of the larger test needed to run where. How you do this is left wide open, in some cases we had the server side test query the autotest server via RPC to fetch more info about the hosts (their list of host labels in particular). In others, maybe you already know enough based on hostnames alone or maybe you have a separate machine information service that you can query. You could also divine what each of the hosts are by accessing them directly via host objects to look at their hardware configs. It really depends on how you want to set things up. There is code under server/frontend.py that can be used to query the autotest frontend via RPCs to get host information from the autotest server. The main point is that this logic is done within the autotest test itself. The autotest scheduler isn't able to do anything for you beyond give you a group of machines (either a specific exact set using a label + sync count, or a somewhat variable set of at least sync count hosts by using an atomic group label). -gps
_______________________________________________ Autotest mailing list [email protected] http://test.kernel.org/cgi-bin/mailman/listinfo/autotest
