Day 8

This post may be unfinished. My research has since ended and I decided that the benefits of this blog did not outweigh the time required to continue writing posts. I have decided to post the unfinished posts for continuity's sake.

Taking a step away from virtualization and toward maximizing the resources on the local computer I began working on a modification of the previous system to run multiple tests on the single machine.

The first step was to write a python script that spawn multiple instances of the bitten slave. The script spawns one instance of bitten for each core the system has. Each instance is spawned in a child process with a unique port number stored as an environment variable. This will be important shortly for queuing up test jobs.

I then worked on writing a bitten recipe that simply calls a local python script, and passes it command line arguments. The location of the local script that the recipe launches, is determined when the recipe is run. The local path to the script is passed by the bitten slave (in the bitten slave configuration file) to the bitten server at connection time. When it connects the bitten server, it tells the server the local path to the script it should run allowing the script to sit anywhere locally and the server to delegate tests to it without the server knowing where the script sits locally.

The next step was to write the script the recipe would call. The script sits on the local machine (which runs the bitten slave as well). It gets called with some set of command lines arguments determined by the recipe but it gets called as a sub process of the bitten client requesting the build configuration (ie requesting the test recipe) from the server.

The script can now spawn a new instance of GraspIt and tell it to listen for commands on a specific port (based on the environment variable that was set when the bitten slave was originally spawned). The script can then use the command line arguments passed by the recipe to run specific tests on GraspIt by sending these tests to the GraspIt socket listening on the designated port.

From here I started working on a way to generate the recipes in batch format. Since the idea was to use each recipe to run a single test or a single set of tests, we wanted to be able to create many recipes with slightly changed parameters very easily and quickly. The first step was to take the recipe I had made originally and parametrize it so that many recipes could be generated from a set of parameters. The first version of this program simply spat out a file with many recipes in it one after the other. We had hoped bitten had a way of easily adding recipes using a batch upload or something of the kind. Unfortunately we found no such thing so the next task was to create a method to add recipes to the system in bulk.

The solution was to use the general recipe addition methods (a set of web based forms) but in an automated fashion. To do this I would write a python script using the mechanize library that would automate both the process of generating the recipe given some set of parameters, and adding it to a new build configuration on the bitten server.

From reading the mechanize documentation and tutorials online you quickly see what a great tool it is. The first obstacle was getting the authentication process to properly recognize my script. Since Trac and bitten don't use forms on pages for login and rather use basic authentication (or in some cases digest authentication) pointing mechanize directly to the admin page doesn't work. Instead you must load your user name and password into mechanize, point it to the login page, and the redirect to the admin page. If you aren't logged in, attempting to load the admin page directly will return a 404 error, not prompt you to log in.

After getting the log in process to work properly, creating a new build configuration (to hold a recipe) is fairly straight forward. Adding the recipe to the build configuration on the other hand is unfortunately not. Mechanize doesn't play so nicely with the way the form is laid out in bitten. The default submit button is the cancel button and getting the form to submit with the save button seems to be an issue many people have dealt with with other applications.

See: http://stackoverflow.com/questions/734893/python-mechanize-two-buttons-of-type-submit

Next week starts out by trying to find a solution.

Day 7

This post may be unfinished. My research has since ended and I decided that the benefits of this blog did not outweigh the time required to continue writing posts. I have decided to post the unfinished posts for continuity's sake.

Today I worked on building clones of virtual machines. The idea is to configure a single virtual machine the way we need to run these tests, and then distribute clones of this machine to many different computers in the lab. The virtual machine can just run in the background, requesting new test and running them in the virtual environment.

After figuring out the cloning process (not such a difficult process at all) I was working on configuring "teams" of virtual machines. Teams can be thought of as virtual labs, or banks of computers that you can interact with as a group. The goal of this was to have teams of computers running in the virtual environment rather than just a single computer and thus be able to run multiple instances of GraspIt in different virtual environments, getting a speed up on multi core systems by running it in parallel, without having to worry about multithreading the code, or worrying that GraspIt won't play nicely with other running instances. If anything should crash or not work as expected, it would happen in the virtual environment and not affect the the main environment of the computer.

I also worked on scripting the start-up and shutdown of the virtual teams, with the idea that a single command at the computer could start or stop the simulation and without dealing with any of the inner workings of the programs. That is, each individual virtual machine would always have a a bitten slave running, requesting tests, and from the main machine you could control if the "virtual lab" was on or off.

The number of things that can be scripted easily with the basic command line interface of VMware Workstation is somewhat limited however. I therefore looked into using VMware ESX and a more server dependent environment since it allowed for a wider range of scriptable functionality. Most likely though, this is overly complicated for this stage of the project.

Day 6

This post may be unfinished. My research has since ended and I decided that the benefits of this blog did not outweigh the time required to continue writing posts. I have decided to post the unfinished posts for continuity's sake.

Today I picked up where we had left off- dealing with the MKL linking error.
After much playing around and testing, I figured out there was an issue with one of the path variables.

Finally, everything compiled and ran, but a new obstacle popped up.
Anytime a file was loaded, GraspIt would throw runtime errors and crash.
We think this may have something to do with the way Qt was compiled.
We decided to move on to other aspects of the project because we already had a working copy of GraspIt (on several other machines, on several other operating systems), and this aspect of the project was mostly and exercise in getting GraspIt to run on the virtual machine using freshly downloaded components, rather than the main goal of the project.

With that in mind, I began work on building a bitten recipe that would launch GraspIt. The idea was to use build configurations to check out the most recent version of GraspIt from the repository and then run it with a collection of test configurations to test different grasps. By using Bitten to handle the delegation of tests, we don't have to worry about maintaining test state on any single machine. Each machine simply queries Bitten for a set of tests and runs them, returning results to Bitten if desired. Bitten keeps track of which tests have been run, so we don't run the same test multiple times for no reason.