Confirmed users
1,927
edits
Auto-tools/Projects/MozPool/LocalTesting: Difference between revisions
Jump to navigation
Jump to search
Auto-tools/Projects/MozPool/LocalTesting (view source)
Revision as of 02:36, 20 November 2012
, 20 November 2012no edit summary
(Created page with "= 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 i...") |
No edit summary |
||
| Line 5: | Line 5: | ||
First copy mozpool/config.ini.dist to mozpool/config.ini. Edit the new file, and change | 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) | * [database] engine to something like sqlite:////some/path/mozpool.sqlite (yes, the path part begins with ''four'' slashes) | ||
* [server] fqdn to local | * [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). | * [mozpool] b2g_pxe_config to image1 (this is a fake image created by the testdata program below). | ||
| Line 12: | Line 12: | ||
Finally, run "mozpool-server". | 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. | 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. Line breaks are just for clarity. | ||
curl --data '{"boot_config": {"version": 1, "b2gbase": "http://some.random.url/"}, "assignee": "mcote", "duration": | curl --data '{"boot_config": {"version": 1, "b2gbase": "http://some.random.url/"}, | ||
"assignee": "mcote@mozilla.com", "duration": 600}' '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"]. | 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"]. | ||
| Line 22: | Line 23: | ||
You can see the request state with | You can see the request state with | ||
curl 'http://local | curl 'http://<local hostname>:8080/api/request/1/status/' | ||
and the device state with | and the device state with | ||
curl 'http://local | curl 'http://<local hostname>:8080/api/device/<assigned device>/status/' | ||
replacing | 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 | Now simulate a successful power cycle with | ||
curl -X POST 'http://local | curl -X POST 'http://<local hostname>:8080/api/device/<assigned device>/event/power_cycle_ok/' | ||
again replacing " | 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 | curl -X POST 'http://<local hostname>:8080/api/device/<assigned device>/event/b2g_downloading/' | ||
curl -X POST 'http://local | curl -X POST 'http://<local hostname>:8080/api/device/<assigned device>/event/b2g_extracting/' | ||
curl -X POST 'http://local | curl -X POST 'http://<local hostname>:8080/api/device/<assigned device>/event/b2g_rebooting/' | ||
curl -X POST 'http://local | 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. | You'll probably need to wait a (very) short time between these commands due to threading and such. | ||
| Line 45: | Line 46: | ||
Finally, check the request state: | Finally, check the request state: | ||
curl 'http://local | curl 'http://<local hostname>:8080/api/request/1/status/' | ||
It should be in the "ready" state, as is the device. | It should be in the "ready" state, as is the device. | ||
| Line 51: | Line 52: | ||
If you check the request details with | If you check the request details with | ||
curl 'http://local | curl 'http://<local hostname>:8080/api/request/1/details/' | ||
you'll see the expiry time. You can always renew the device by something like | you'll see the expiry time. You can always renew the device by something like | ||
curl --data '{"duration": 300}' 'http://local | 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. | 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. | ||
| Line 61: | Line 62: | ||
Finally, you can return the device and end the request with | Finally, you can return the device and end the request with | ||
curl -X POST 'http://local | 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. | 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. | 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. | ||