Kiss the old testing infra (Revision 3 Mac minis) goodbye

It is with great joy that today we are turning the page on our old Release Engineering infrastructure. Since Q1 2010, we have run unit tests and talos jobs on rev3 Mac minis which have seen seven different end-user operating systems: xp, win7-32/64-bit,10.5, 10.6, Fed12 32/64-bit. We stopped support for OS X 10.5 and moved our 10.6 tests to rev4 Mac minis over the past two years, and back in April we moved most of our Fedora32/64-bit test/talos jobs to Ubuntu32/64 VMs in AWS and on iX hardware.

I'm so high! Have you seen this infra? It's magical! Rainbows for you and me.

Several weeks ago, we had another major milestone in the transition of the XP and w7 architectures when new iX machines (the same type of hardware we used for Ubuntu and Windows 8) started arriving at our Vantage data center in Santa Clara.  Thanks to DCOps and RelOps, we got them up and running this May, and we enabled identical test jobs on them.  Today, we are disabling unit tests and talos jobs on our old Rev3 Mac mini machines for Firefox 23 and Firefox 24 development trees for Windows XP and Windows 7.  This change moves the last two platforms off the rev3 minis and allows them to be retired once they finish riding the trains for ESR17 in December.

What is shiny about this infrastructure? 

Q Fortier and Mark Cornmesser (from RelOps) wrote steps for the initial installation using Microsoft's WDS/MDT framework, which allows for modular, shared task sequences between systems. Changes to the machines can be made after the fact using Microsoft's GPO (Group Policy Object), and, in the future, support will also be added for puppet.  This is the same setup as with our new Windows 8 infrastructure. This helps us deprecate our lovely (...not) OPSI system and it takes away the pain of deploying things manually through VNC or SSH (I know, I know :S ) on our Win7 machines.

Another neat thing is that we will be able to remotely power cycle these machines like the rest of our infrastructure since they have out-of-band management support via IPMI. We can also increase capacity of this infrastructure more easily than the Mac minis since the iX hardware has a longer and more predictable purchasing lifecycle than Apple machines.

We now have 130 nodes for each Windows flavor (Win8, Win7 and WinXP) taking care of all of the jobs on mozilla-central based trees plus mozilla-aurora.  For now, the rev3 machines will ride the trains until ESR17 is killed in December. We could try to fast track this process by uplifting some patches but we don't see a pressing reason to add more human hours into it.

It's been a pleasure to be part of this large testing infrastructure refresh and working together with arr, coop, dmoore, dustin, edmorley, Fredo, hwine, Hubear, markco, melissa, philor, Q, rail, RyanVM, tfranco, van, vinh, sal and devs. My apologies if I missed anyone.

If you're curious, all 5 different operating systems were set up under this huge tracking bug: https://bugzilla.mozilla.org/show_bug.cgi?id=820243

iX systems:

http://www.ixsystems.com

EDIT: 30-May: I added few more people to the thank you list.

---

This work by Zambrano Gasparnian, Armen is licensed under a Creative Commons Attribution-Noncommercial-Share Alike 3.0 Unported License.

Yesterday's load

I will do a longer analysis at some point but I would like to share with you a link and a screenshot of it.

These two diagrams show commits over 24 hours (from Mon, 11 Apr 2011 00:00 PDT to Tue, 12 Apr 2011 00:00 PDT) from all of our currently supported project branches. On the first diagram we can see pushes per hour and on the second diagram we can see a distribution of these pushes among the different project branches.

Each one of these commits produce different types of builds and tests. For a given build we can end up queuing up to 14 test suites plus 8 different talos jobs for a given OS.
How easily can the test pool be out of capacity? Three builds of a certain OS finishing around the same time can generate up to 66 testing jobs and take up more than the whole testing pool for that OS (we have 48 to 54 machines per OS) for a variable amount of time. Test jobs can take from 5 minutes to more than 60 minutes depending on the OS and the test suites.

For further information on test times I have some raw data from back in December (out-of-date warning) and three blog posts where I drew conclusions out of it.

This high load of pushes and the conglomeration of pushes (how close they are to each other) make test jobs to be queued and wait to be processed (this can be seen on the daily Wait Time emails on dev.tree-management). We need more machines (and we are working on it) but here are few things that you can do to improve things until then:

• Use the TryChooser syntax. Spending a moment to choose a subset of build and test jobs for your change helps to use the right amount of resources. If you need all builds and tests do not hesitate to use it all. Note that at some point this syntax will be mandatory.
• Cancel unneeded jobs. Use self-serve (which shows up on tbpl) to stop running or pending jobs once you know that they are not needed because you pushed something incorrectly or it is going to fall  Once a build or test is not needed please cancel it to free up resources. Everyone will thank you.

There are also things that could be fixed like improving reftests and xpcshell for Win7 but that is not something that everyone can help in a reasonable amount of time.

[EDIT] 4:15pm PDT - I want to highlight that there is going to be a series of blog posts explaining what is the work and new testing machines purchase that we will be undertaking to handle such bad wait times.

---

This work by Zambrano Gasparnian, Armen is licensed under a Creative Commons Attribution-Noncommercial-Share Alike 3.0 Unported License.