View source for Auto-tools/Projects/WebRTC Cloud Automation/Meetings/2013-07-02

Goal of this get-together, introduce the new team to one another, define the concrete goal we want to achieve this quarter, break it down and assign tasks to get started.
= Agenda =
* Quick Intro  2mins, total, max
* What is our goal for this automation at the end of this quarter?
* What are the milestones to reach that goal?
* What are the steps do achieve the first milestone and who's on point for each of them?
== Housekeeping items ==
* How are we going to track progress? Bugzilla, I assume?
* Where will the code live?
* Ongoing weekly? meeting?  Bi-weekly? Does this time work?
--> Scheduling  a weekly meeting for now, we can always change it later.
= Notes =
<pre>
* Stand up arena of servers + clients
** Describe necessary resources
** Spin up VMs for each, run specified code on each
** Collect results
* Initial reporting: just email?
* We need to be able to scale eventually (not just for webrtc)
from ekr:
- Ability to run tests that involve multiple machines
 * Will be running large volume of tests
 * In multiple network configurations
- A set of WebRTC tests that run between two machines on different networks
   * Standalone C++
   * In the browser (similar to Mochitests)
- A set of signaling, STUN, and TURN servers to enable the above tests.
* Pre-canned, not really configurable (software already exists)
* Can be shared between environments
* Network configuration between hosts more important
* Different clients behind different NATs to make STUN server do useful work
* Signaling server needs to exist - exchange offer/answer (existing prototypes for this)
- Ability to reconfigure the network environment for a given machine
   * So that it sits behind a specific NAT/firewall
- Support for the usual variety of hardware/OS
- Verification of audio/video quality and flow
- Support for limited network environments and verification that A/V compensates.
- Which infrastructure should this run on?
* ekr has existing Buildbot infra
* RelEng infra
What should we call this project? 
* ted will pick a name
Architecture
Super helpful to have a visual depiction of the client/server configuration(s)
--> Here is a potential idea for how this might work:
--> https://wiki.mozilla.org/Auto-tools/Projects/ServicesAutomation_Proposal
--> What are the useful pieces of infrastructure that a test would want to be able to configure? How many of those are top priority to have something useful turned on by end of quarter?
--> Can we reuse releng code to startup/shutdown machines?
* RelEng is using Boto to communicate with AWS instances (https://github.com/boto/boto)
* Start script: http://hg.mozilla.org/build/cloud-tools/file/5e627ea3e624/aws/aws_watch_pending.py
* Stop script: http://hg.mozilla.org/build/cloud-tools/file/5e627ea3e624/aws/aws_stop_idle.py
* Rail says Boto is working well for them, other than the fact it is a synchronous interface
--> We should also mirror the existing test VMs as best we can from releng so that we are working in a known environment (and as an aside if we need one, we can probably snag a releng engineer to help us out here...remains to be seen if we need it).
Dependencies 
- Not tpbl v2 but they could be closely related 
- 
</pre>