Problem

It's been historically difficult for developers to find and use an automation-ready mobile device. The devices they typically have at their disposal are not automation-configured and as a result are not great candidates for reproducing/diagnosing test failures that occur in the buildbot automation system.

As we begin to use more different devices for our automation, we will exacerbate this issue because we will reach a point where we cannot buy all the developers a device to hack on.

Goals & Considerations

• Provide an easy web-dashboard to "check out" a mobile device
• Configure the device properly on check out so that the developer has a ready and working system with debugging information turned on, IP addresses, agents etc.
• Provide a mechanism for the developers to "check-in" a device
• Checking in a device causes a reflash/reboot so that the device is returned to a known good state and is ready for the next use.
• The system should be sufficiently generalized so that any device can be used - i.e. a general interface for flashing the device should call into a tegra specific method for flashing a tegra, or should call into a windows mobile device specific method for that type of device etc.
• The system should provide a dashboard so that we can glance at the system and know what state the machines are in.
• We should also be able to ping the developers that have devices checked out, so we'll need to acquire their email.
• This should probably be behind an L1 LDAP access prompt.

Design Proposal

• Since we require LDAP access anyway, we can use the credentials provide links to phonebook.m.o for contact information
• the home page should be a dashboard of available devices, devices in use by the user, and other devices in use (appropriately presented if there are many) with a [Checkout] option
• checkout will provide appropriate information and device setup and set this devices as the user's
• you can also check in a device from a home page
• optionally, we could limit N devices per user (where N might be one)
• devices interfaces should be pluggable; that is, you have an interface which is implemented per type of device. the technicalities of configuration are done through an e.g. setup() method of this interface, as well as querying of device state and other desired functionality
  • in a more advanced system, not all devices would necessarily have all capabilities

Non-Goals

• Re-design the pool system that releng is using for their buildbot automation -- this will be a separate pool specifically for the developers

Design and Approach

I think this is a case where we should prototype a system before building the entire thing. It's not clear how much uptake a system like this will have in developer circles and so a prototype will be a good thing to have to try and gauge that. We can prototype with just tegra boards and see how it goes.

We should be able to rely pretty heavily on the prior work done on:

• the devicemanager.py
• the releng sut-tools
• the sutagent

Prototype

A Prototype has been made! Web front end is a templeton server. Database is mySQL. Python script picks up any new tegra that checks in and adds them to the database. It is on the mountainview network located at: http://10.250.2.108:8080, now http://tegrapool.private.mtv1.mozilla.com/. The code is found at https://github.com/tfairey/TegraPool/

If running remotely, the user simply checks the "I am working remote" box, and then submits the build that they would like to run tests on. When checkout is pressed, a temporary user account is created on the server, and everything "SHOULD" be ready to run tests once the user logs in. To immediately run mochitests, for example, simply ssh in, and type ./runMochiRemote.sh

Tegras

Tegra 1: 10.250.6.17

Tegra 2: 10.250.2.32