Within the UTAH code, provisioning machines is handled by subclasses of the Machine class.
Scripts should provision machines by creating an instance of a subclass of the Inventory class, and using the Inventory.request() method to obtain a machine. Inventories are intended to prevent resource collision.
End users not writing scripts can provision machines automatically using scripts provided by the UTAH package. Please see the main UTAH page for that.
By default UTAH uses a preseed stored as /etc/utah/default-preseed.cfg for the provisioning of the test machine. By giving a -p preseed_file input to UTAH a custom provisioning could be carried out.
For example, the following command would provision the test machine with quantal server image with the options given in the contents of preseed_file and run the post installation tests given in master.run:
sudo -i -u utah /usr/share/utah/examples/run_utah_tests.py \
-i http://cdimage.ubuntu.com/ubuntu-server/daily/current/quantal-server-i386.iso \
-p /absolute_path_to/preseed-file /absolute_path_to/master.run
An example preseed for precise is given in the Ubuntu Installation Guide.
As UTAH codebase becomes more stable, there’s an effort to make it not only work correctly, but also look correctly. To do that, we’re using flake8, a static code analysis tool that is a combination of both pyflakes and pep8. This way, both syntax and PEP008 errors can be checked in a single shot.
PEP008 (Python Enhancement Proposal 8) is a document that contains a set of style guidelines for developers written by Guido van Rossum and Barry Warsaw. It’s commonly accepted as the de facto style document for python developers; so, unless we don’t find useful after some time, we decided to adopt it.
Aside from PEP008, the Google Python Style Guide has received some attention as well. Since it differs from PEP008 at some places, this one isn’t being followed at this time, but some part of it could be used in the future.
Another tool that has a very good reputation is pylint. While it’s a very useful tool, it’s a little bit more difficult to use and requires some time to configure it to adapt to the policy of a given project. Anyway, it could be used in the future as well to catch some of the errors/warnings that might not be detected by flake8.