On 13-10-17 3:22 PM, Armen Zambrano Gasparnian wrote: > Option #3 sounds logical. Based on feedback I received from joduinn, one small adjustment to option #3: phase-in to "try" first and wait for confirmation before phasing-in inbound/central to further reduce risk exposure to those branches.
> > What way would sheriffs/devs have to determine which machines are rev2 > and which ones are rev1? > Should they use the info in production_config.py? > - rev2 machines: [1] > - rev2 (try): currently empty [2] Yes, using production_config.py would be a sure way to tell the difference. You can also tell them apart by looking at the build root in a build log: rev1 - e:\builds\moz2_slave rev2 - c:\builds\moz2_slave John > > [1] > http://hg.mozilla.org/build/buildbot-configs/file/production/mozilla/production_config.py#l8 > [2] > http://hg.mozilla.org/build/buildbot-configs/file/production/mozilla/production_config.py#l33 > > On 2013-10-17 2:34 PM, John Hopkins wrote: >> Here are three different proposals to cut over to the new Windows 64-bit >> rev2 (win64-rev2) machines (see >> https://groups.google.com/forum/#!topic/mozilla.dev.platform/zACrUe_JwKw >> for context), along with some of the pros and cons of each approach. >> I would prefer option #3 (gradual phase-in) so long as we're okay with >> having a mixed pool of rev1/rev2 win64 build machines on the same >> branches. Timing will depend on which option we go with. >> >> Please let me know as soon as possible your preference or whether you >> have any other comments/concerns. I will assume option #3 if there are >> no objections by end of day Friday. >> >> In addition, I'd like to have a smoke test performed against the Windows >> builds on one of our project branches (which have already been cut over) >> - fx-team or ux seem like good candidates. I will follow up with the >> QA team. >> >> >> Win64-rev2 Cutover Proposals: >> >> 1) Cut over all of inbound/try/central to win64-rev2 over a weekend. >> Pros: >> - all branches built using the same machine image >> - lowest volume of checkins happen on weekends, so less wait time impact >> Cons: >> - "big bang" upgrade. If someone discovers an issue on Monday, a >> lengthy downtime could be required to resolve it. >> - build wait times on the weekend could be lengthy or require a tree closure >> - staffing weekend work is problematic >> >> >> 2) Cut over inbound/try/central branches one at a time, each early on a >> Monday (over several weeks) >> Pros: >> - more people around to find/fix problems >> Cons: >> - longer wait times >> - not all branches using the same build machine image >> - longer cutover time >> >> >> 3) Gradual phase-in of win64-rev2 machines on inbound/try/central in a >> mixed rev1/rev2 pool >> Pros: >> - limited impact of bustages (due to mixing in a small number of rev2 >> build machines to start and gradually increasing) >> - no impact on wait times (could even improve them slightly since we're >> a bit low on rev1 capacity at the moment) >> - no weekend work required, can be done during the week as time permits >> Cons: >> - mix of rev1/rev2 build machines, mitigated by having exclusively rev2 >> allocated to project branches for testing rev2-specific bustage fixes >> >> >> Note: This will not impact release branches (aurora, beta, release, >> esr). We will cut over to those branches only once win64 rev2 has been >> proven on inbound/try/central. Bug 781277 is the overall tracking bug. >> >> Thanks, >> John >> > _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
