Confirmed users
1,927
edits
Auto-tools/Projects/MozPool: Difference between revisions
no edit summary
(Created page with "= Goals = MozPool is a simple service to manage a pool of devices. The main goal is to integrate it into buildbot for running mobile/B2G unittests, as part of the future foopy-l...") |
No edit summary |
||
| Line 15: | Line 15: | ||
= Requirements = | = Requirements = | ||
# | # MozPool should provide a mechanism for devices to register themselves with it. This may be through the SUTAgent registration protocol, or by querying an inventory server. | ||
# Once a device is registered with MozPool, it should track its state. | # Once a device is registered with MozPool, it should track its state. | ||
# MozPool should provide a web UI that users can use to see the status of connected devices, check them out, and check them back in again. | # MozPool should provide a web UI that users can use to see the status of connected devices, check them out, and check them back in again. | ||
# MozPool should provide an API with which remote components can interact with it (via TCP sockets or HTTP), and should include the following. Note that these may be proxied to Lifeguard or a similar service. | # MozPool should provide an API with which remote components can interact with it (via TCP sockets or HTTP), and should include the following. Note that these may be proxied to Lifeguard or a similar service. | ||
## an API to request a device for testing. This API should accept some parameters: processor (armv6 vs armv7), hardware type (panda, ...), pool (b2g vs mobile), and potentially android version. It should return an identifier of a device that it has a valid recent ping, and then mark the status of the device accordingly (e.g., 'checked_out'). | ## an API to request a device for testing. This API should accept some parameters: processor (armv6 vs armv7), hardware type (panda, ...), pool (b2g vs mobile), and potentially android version. It should return an identifier of a device that it has a valid recent ping, and then mark the status of the device accordingly (e.g., 'checked_out'). | ||
## an API to return a checked_out device to the pool. This API should accept a device identifier. After being returned to the pool, MozPool should ask Lifeguard to reboot the device (?) and verify it is alive, after which the status should be updated to online. | ## an API to return a checked_out device to the pool. This API should accept a device identifier. After being returned to the pool, MozPool should ask Lifeguard to reboot the device (?) and verify it is alive, after which the status should be updated to online. | ||
## an API to set the status of the device (offline or online) and to attempt rebooting or resetting its power. | |||
### If a user marks a device as online, Lifeguard should attempt to bring the device online; if it fails, it should return the status to offline. | |||
## an API to flash a given B2G build on a device (do we need to be able to flash fennec boards as well?). | ## an API to flash a given B2G build on a device (do we need to be able to flash fennec boards as well?). | ||
## an API to reboot a device, given its identifier. | ## an API to reboot a device, given its identifier. | ||
| Line 29: | Line 29: | ||
## an API to set the current state of a device, given its identifier. | ## an API to set the current state of a device, given its identifier. | ||
## additional APIs needed to support the Web UI above | ## additional APIs needed to support the Web UI above | ||
# | # MozPool should scale to handle a large number of devices (several hundred, exact number still TBD) | ||
# | # MozPool should have unit tests, that we can run before committing changes. | ||
# | # MozPool should have a staging environment, and integration test that we can run in a live environment. | ||
# | # MozPool should maintain a detailed log including, among other things, details on device registrations, device state transitions, and all API requests. | ||
# | # MozPool should be well-documented. | ||