Testing Mozpool Locally

You can test at least the high-level aspects of mozpool locally without a real device, e.g. to see how requests work. You won't be able to actually image devices, obviously, but you can simulate the device events to see the full request flow.

First copy mozpool/config.ini.dist to mozpool/config.ini. Edit the new file, and change

• [database] engine to something like sqlite:////some/path/mozpool.sqlite (yes, the path part begins with four slashes)
• [server] fqdn to <local hostname>:8080 (e.g. the output of python -c "import socket; print socket.getfqdn() + ':8080'")
• [mozpool] b2g_pxe_config to image1 (this is a fake image created by the testdata program below).

Then run "mozpool-db create-schema" followed by "mozpool-db run testdata.py -p 8080 -d 5". This will set up your local database with a fake imaging server and five fake devices. Take a look at testdata.py for other options.

Finally, run "mozpool-server".

To see a request go through, run these commands in another terminal (append "| python -m json.tool" to have the output JSON pretty-printed). Note that you must use the fqdn that you set in the config above; otherwise you'll just get redirects.

 curl --data '{"b2gbase": "http://some.random.url/", "assignee": "mcote@mozilla.com", "duration": 600, "image": "b2g"}' 'http://<local hostname>:8080/api/device/any/request/'

This creates a request for any ready device and to install a b2g build on it. If you leave off the "boot_config" object, it will just request a power cycle. In the resulting JSON you should see, amongst other things, that request["assigned_device"] is set to some random device and request_url to a URL fragment of with the same id as request["id"].

In the mozpool-server terminal, you'll see log messages about the device entering "pxe_power_cycling" and a "Connection refused" error, which is expected since the test data uses a fake relay server. There should also be log messages about the request moving through the states "finding_device", "contacting_lifeguard", and "pending".

You can see the request state with

 curl 'http://<local hostname>:8080/api/request/1/status/'

and the device state with

 curl 'http://<local hostname>:8080/api/device/<assigned device>/status/'

(note <assigned device> is something like device1 as assigned by the testdata)

replacing <assigned device> with whatever device was given in request["assigned_device"] when the request was created. It should be in the "pxe_power_cycling" state, and you'll see a number of log messages.

Now simulate a successful power cycle with

 curl -X POST 'http://<local hostname>:8080/api/device/<assigned device>/event/power_cycle_ok/'

again replacing "<assigned device>" with your assigned device. mozpool-server should say that the device moved to the state "pxe_booting". Simulate a successful boot and install with these fake events:

 curl -X POST 'http://<local hostname>:8080/api/device/<assigned device>/event/b2g_downloading/'
 curl -X POST 'http://<local hostname>:8080/api/device/<assigned device>/event/b2g_extracting/'
 curl -X POST 'http://<local hostname>:8080/api/device/<assigned device>/event/b2g_rebooting/'
 curl -X POST 'http://<local hostname>:8080/api/device/<assigned device>/event/ping_ok/'

You'll probably need to wait a (very) short time between these commands due to threading and such.

Finally, check the request state:

 curl 'http://<local hostname>:8080/api/request/1/status/'

It should be in the "ready" state, as is the device.

If you check the request details with

 curl 'http://<local hostname>:8080/api/request/1/details/'

you'll see the expiry time. You can always renew the device by something like

 curl --data '{"duration": 300}' 'http://<local hostname>:8080/api/request/1/renew/'

If you check the details again, you'll see the expiry date has been updated with the new duration (note that this overwrites the previous expiry; it does not add to it). If the expiry datetime passes, the request will move to the "expired" state and the device will be released.

Finally, you can return the device and end the request with

 curl -X POST 'http://<local hostname>:8080/api/request/1/return/'

which will result in the request moving to the "closed" state and release the device. You can close expired request or requests in other error states, but it doesn't do anything except move to the closed state.

There are timeouts and retries for requests for "any" device, if you want to play with those (feel free to temporarily modify values in mozpool/mozpool/requestmachine.py to speed this up), and there are appropriate error states if all devices are busy or if a specific device is requested but busy.