Auto-tools/Projects/WebRTC Cloud Automation/Meetings/2013-07-02
From MozillaWiki
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
* 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 -