Confirmed users
1,927
edits
Auto-tools/Projects/MozPool: Difference between revisions
Jump to navigation
Jump to search
no edit summary
No edit summary |
|||
| Line 40: | Line 40: | ||
* What is the best way to handle the API calls that just pass through to Lifeguard? Note that it's important to use MozPool for these actions (e.g. pinging, rebooting, etc.) so that MozPool doesn't assign the device out to someone else while Lifeguard is working on it. | * What is the best way to handle the API calls that just pass through to Lifeguard? Note that it's important to use MozPool for these actions (e.g. pinging, rebooting, etc.) so that MozPool doesn't assign the device out to someone else while Lifeguard is working on it. | ||
* If Lifeguard/BMM is responsible for installing a particular build of Fennec or B2G on a device before returning it (which makes sense, as it abstracts this operation away from the test harnesses), it may take some time for a check-out operation to complete. Is it acceptable to leave the connection open during this time, or should we use a callback mechanism? If the latter, we'll definitely need a Python client library to simplify the procedure. | * If Lifeguard/BMM is responsible for installing a particular build of Fennec or B2G on a device before returning it (which makes sense, as it abstracts this operation away from the test harnesses), it may take some time for a check-out operation to complete. Is it acceptable to leave the connection open during this time, or should we use a callback mechanism? If the latter, we'll definitely need a Python client library to simplify the procedure. | ||
= API = | |||
<id> can be "all" or "any" for most apis (except release) | |||
* (future) can include json body with "filter" property and these subproperties: | |||
** type: phone, panda, tegra (?) | |||
** model | |||
** os | |||
* "all" returns all matching devices, "any" returns a random one | |||
/api/device/ | |||
* lists all devices | |||
/api/device/<id>/ | |||
* info on device <id>. | |||
/api/device/<id>/request/ (POST) | |||
* requests device <id>. device is only returned if state is IDLE. | |||
** can have following json properties in body: | |||
** fennec: fennec build ID (path?) | |||
*** Installs build before returning device | |||
** b2g: b2g build ID (?) | |||
*** Flashes build before returning device | |||
** callback: IP address and port, for asynchronous notification | |||
If 'callback' is not given, waits until the build is installed and device | |||
verified, then sends back device info with new state (200 if state is ASSIGNED, | |||
other code otherwise). If callback given, responds with 200 OK then calls | |||
callback when device is ready (or errored) with JSON result | |||
/api/device/<id>/release/ | |||
* releases device <id>. | |||
** can have following json property: | |||
*** state: should be IDLE or ASSIGNED or particular error | |||
/api/device/<id>/verify/ | |||
* launches a verify operation on device (same as when device is assigned) | |||