Confirmed users
1,905
edits
Auto-tools/Projects/Lifeguard: Difference between revisions
Jump to navigation
Jump to search
→Requirements
| Line 14: | Line 14: | ||
# Lifeguard should provide a mechanism for devices to register themselves with it. | # Lifeguard should provide a mechanism for devices to register themselves with it. | ||
# Once a device is registered with Lifeguard, it should periodically ping the device to verify that it's still alive. | # Once a device is registered with Lifeguard, it should track its state, and should periodically ping the device to verify that it's still alive. | ||
## If the ping fails, Lifeguard should attempt to recover the device by resetting its power up to N times. | ## If the ping fails, Lifeguard should attempt to recover the device by resetting its power up to N times. | ||
## If resetting the device fails, Lifeguard should mark the device as offline. | ## If resetting the device fails, Lifeguard should mark the device as offline. | ||
| Line 22: | Line 22: | ||
# Lifeguard should provide an API with which remote components can interact with it (via TCP sockets or HTTP), and should include the following: | # Lifeguard should provide an API with which remote components can interact with it (via TCP sockets or HTTP), and should include the following: | ||
## an API to request a device for testing. This API should accept some parameters: processor (armv6 vs armv7), hardware type (panda, ...), and pool (b2g vs mobile). 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, ...), and pool (b2g vs mobile). 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, Lifeguard should 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, Lifeguard should reboot the device (?) and verify it is alive, after which the status should be updated to online. | ||
## an API to reboot a device, given its identifier. | |||
## an API to reset the power on a device, given its identifier. | |||
## an API to get 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 | ||
# Lifeguard should scale to handle a large number of devices (several hundred, still TBD) | # Lifeguard should scale to handle a large number of devices (several hundred, exact number still TBD) | ||
# Lifeguard should have unit tests, that we can run before changes. | # Lifeguard should have unit tests, that we can run before committing changes. | ||
# Lifeguard should have a staging environment, and integration test that we can run in a live environment. | # Lifeguard should have a staging environment, and integration test that we can run in a live environment. | ||
# Lifeguard should maintain a detailed log including, among other things, details on device registrations, device state transitions, and all API requests. | # Lifeguard should maintain a detailed log including, among other things, details on device registrations, device state transitions, and all API requests. | ||
# Lifeguard should be well-documented. | |||