Below is a summary of how to use the job server in Assignment 4 To launch a job into our Amazon batch queue type:

python launch_amazon.py --qsub 4 --test hello418.txt

This command enqueues a job in our job system that will launches your server on Amazon and drive it with the specified test. (Notice thatu unlike run.sh you just use the test filename. Do not specify the /tests directory.). The argument --qsub 4 specifies that the run will use up to 4 worker nodes. (Note this does not spawn four workers, the master node of the server must still do this. The argument just configures our runtime system so that the master is allowed to spawn the specified number of workers. Requests that go beyond this number are ignored.

Submitting a job should result in the following output.

Uploading src/myserver directory to AWS...
myserver/
myserver/master.cpp
myserver/worker.cpp
Queuing test: hello418.txt
Added job to queue: 000000001_kayvonf
Max workers = 4

The script has now uploaded the contents of your src/myserver directory to our job system on AWS, and it has scheduled your server to run when machines become available. The job id for your job is given. Here, its: 000000001_kayvonf. Obviously, when you run the command you will get a unique job identifier. You'll need to remember this id to get the logs from the job later.

To view the status of the job queue type:

python launch_amazon.py --qstat

Note our current implementation only shows enqueued jobs. Jobs that are already running on machines are not shown.

When your job is complete, to retreive output logs for your job type:

python launch_amazon.py --logs 000000001_kayvonf

If the job is complete, logs containing the output of run.sh, your master node, and all worker nodes will be unzipped into your local directory.

logs_000000001_kayvonf_master/
logs_000000001_kayvonf_master/master_stdout
logs_000000001_kayvonf_master/master.INFO
logs_000000001_kayvonf_master/nodemanager_stdout
logs_000000001_kayvonf_master/workgen
logs_000000001_kayvonf_master/master.ip-10-244-239-79.ubuntu.log.INFO.20130328-220840.31847
logs_000000001_kayvonf_worker1/
logs_000000001_kayvonf_worker1/worker.ip-10-37-53-145.ubuntu.log.INFO.20130328-220848.12724
logs_000000001_kayvonf_worker1/worker.INFO
logs_000000001_kayvonf_worker2/
logs_000000001_kayvonf_worker2/worker.INFO
logs_000000001_kayvonf_worker2/worker.ip-10-242-159-36.ubuntu.log.INFO.20130328-220849.11094
logs_000000001_kayvonf_worker3/
logs_000000001_kayvonf_worker3/worker.INFO
logs_000000001_kayvonf_worker3/worker.ip-10-245-43-1.ubuntu.log.INFO.20130328-220847.19780
logs_000000001_kayvonf_worker4/
logs_000000001_kayvonf_worker4/worker.ip-10-242-253-88.ubuntu.log.INFO.20130328-220849.3533
logs_000000001_kayvonf_worker4/worker.INFO

The most import logs to you are likely:

logs_000000001_kayvonf_master/workgen  (the output of playing the trace)
logs_000000001_kayvonf_master/master_stdout

Useful Notes

As a convenience we offer the following to download the logs from your last job (within the need to specify a job id):

python launch_amazon.py --last

You may also find make cleanawslogs helpful. But BE CAREFUL, it deletes all logs in the working directory.

Our system executes your server for 150 seconds. After this amount of time has elapsed we kill your server, and return the current state of the logs. As a result, if there are empty logs it is likely that your job did not terminate in the appropriate amount of time.