450119 - Buildmaster for unittests on 1.9 is currently qm-rhel02 and needs to move to production-master.build.mozilla.org

Status: RESOLVED FIXED

(Release Engineering :: General, defect, P2)

Description

[Lukas Blakk [:lsblakk] use ?needinfo]

We're bringing the unittest masters over to the build network.

The unittest 1.9 master is currently on qm-rhel02 and will be moved to a master created on production-master.build.mozilla.org

Requesting downtime to be scheduled by IT on Tuesday August 12, 2008 at 8:00 am PDT for 2 hours.

1 hour for IT to bring the following slaves over to the Build network:

(Please change the name of each VM at the same time as moving network)

Current Name   -->   New Name

qm-centos5-01  -->  fx-linux-1.9-slave07.build.mozilla.org
qm-centos5-02  -->  fx-linux-1.9-slave08.build.mozilla.org
qm-centos5-04  -->  fx-linux-1.9-slave09.build.mozilla.org

qm-xserve01  -->  bm-xserve20.build.mozilla.org
qm-xserve06  -->  bm-xserve21.build.mozilla.org

qm-win2k3-01  -->  fx-win32-1.9-slave07.build.mozilla.org
qm-win2k3-02  -->  fx-win32-1.9-slave08.build.mozilla.org
qm-win2k3-pgo01  -->  fx-win32-1.9-slave09.build.mozilla.org

Once that portion is done, this bug can be re-assigned to RelEng.

One additional hour for the non-linux slaves (the linux ones are already prepped) to be upgraded to buildbot 0.7.7 and for all slaves to be reattached to the new master.

Comment 1

[Phong Tran [:phong]]

Can you grab the MAC adress for the 4 physical machines?

qm-xserve01
qm-xserve06
qm-win2k3-01
qm-win2k3-02

Comment 2

[Phong Tran [:phong]]

New names added to DNS.

Comment 3

[matthew zeier [:mrz]]

Pulled MAC addresses from current dhcp:

host qm-xserve01 { hardware ethernet 00:19:E3:E7:E1:2E; fixed-address 10.2.73.11; }
host qm-xserve06-en0 { hardware ethernet 00:17:F2:93:56:E4; fixed-address 10.2.73.137; }
host qm-xserve06-en1 { hardware ethernet 00:17:F2:93:56:E5; fixed-address 10.2.73.137; }
host qm-win2k3-01 { hardware ethernet 00:13:21:1B:F6:3F; fixed-address 10.2.73.13; }
host qm-win2k3-02 { hardware ethernet 00:13:21:B0:4C:86; fixed-address 10.2.73.124; }

Comment 4

[Aravind Gottipati [:aravind]]

Is it possible to start using names that don't have periods in the hostnames?  I raised this question earlier, but it was kind of late in the game then.  Can we switch to normal dns hostnames now?

Comment 5

[Lukas Blakk [:lsblakk] use ?needinfo]

We need to be consistent with the slave names in the build pool - so for now, this means periods.  

I will keep this point in mind for the next round of cleanups, once the unittests machines are all settled into their new homes.

Comment 6

[Phong Tran [:phong]]

Can you let us know when you're ready to move these over to the build network?  The 2 physical XSERVE needs to be rebooted while MRZ configure the ports.

Comment 7

[Phong Tran [:phong]]

All renamed and moved to build network.

Comment 8

[Lukas Blakk [:lsblakk] use ?needinfo]

Please update Nagios - currently it is still pinging the old hosts.

Comment 9

[Aravind Gottipati [:aravind]]

Some of those hosts were not in nagios, I updated those that were.

Comment 10

[Lukas Blakk [:lsblakk] use ?needinfo]

Keeping this open under RelEng for clean ups and comments.

Comment 11

[Lukas Blakk [:lsblakk] use ?needinfo]

Attachment: Upgrade patch - Unittest Production 1.9 to Buildbot 0.7.7

Comment 12

[[e-mail] (:bhearsum)]

Comment on attachment 333627 [details] [diff] [review]
Upgrade patch - Unittest Production 1.9 to Buildbot 0.7.7

>Index: unittest/master.cfg
>===================================================================
>-import auth
>-reload(auth)
>-from auth import *

Why are you removing auth.py?

>-# (bot-name, bot-password)
>-c['bots'] = authList

same as above

> centosFactory.addStep(MozillaCheck,
>         warnOnWarnings=True,
>-        timeout=60*5,
>+        timeout=60*40,

Is there a reason for this change?


>@@ -487,71 +478,71 @@ winxpFactory.addStep(CreateDir,
> winxpFactory.addStep(UpdateClobberFiles,
>         cvsroot=CVSROOT,
>         workdir='.',
>         platform='winxp',
>         logDir='..\\logs\\',
>-        env=MozillaEnvironments['vc8'])
>+        env=MozillaEnvironments['mozbuild'])

Is there a reason for the env change?


--

In the future, can you separate out patches for different features? It makes it tough to review an "upgrade" patch when it include behaviour changes + a11y tests + other things ;-).

Comment 13

[[e-mail] (:bhearsum)]

Comment on attachment 333627 [details] [diff] [review]
Upgrade patch - Unittest Production 1.9 to Buildbot 0.7.7

Lukas, did you see my comments about this patch?

Comment 14

[Lukas Blakk [:lsblakk] use ?needinfo]

(In reply to comment #12)
> (From update of attachment 333627 [details] [diff] [review])
> >Index: unittest/master.cfg
> >===================================================================
> >-import auth
> >-reload(auth)
> >-from auth import *
> 
> Why are you removing auth.py?
> 
auth.py isn't in use on any of the moz2 machines that were running buildbot 0.7.7 so I was following that convention.  I guess it's one less file to keep around and up to date.

> >-# (bot-name, bot-password)
> >-c['bots'] = authList
> 
> same as above
> 
> > centosFactory.addStep(MozillaCheck,
> >         warnOnWarnings=True,
> >-        timeout=60*5,
> >+        timeout=60*40,
> 
> Is there a reason for this change?
> 

i'm not actually sure where this comes from, it's just in the most recent version on the master in use, perhaps a change didn't get reflected in cvs?  the master.cfg in cvs right now is kind of old.

> 
> >@@ -487,71 +478,71 @@ winxpFactory.addStep(CreateDir,
> > winxpFactory.addStep(UpdateClobberFiles,
> >         cvsroot=CVSROOT,
> >         workdir='.',
> >         platform='winxp',
> >         logDir='..\\logs\\',
> >-        env=MozillaEnvironments['vc8'])
> >+        env=MozillaEnvironments['mozbuild'])
> 
> Is there a reason for the env change?
> 
> 

The environment change is just for the paths to work - on the "vc8" environment everything is in C: and in mozbuild it's in D: - also "vc8" used cygwin still.

> --
> 
> In the future, can you separate out patches for different features? It makes it
> tough to review an "upgrade" patch when it include behaviour changes + a11y
> tests + other things ;-).
> 

Sorry about the a11y stuff, I was working with the most recent master.cfg on buildbot 0.7.7 staging, and since the a11y stuff was on there, I left it in.  If you prefer, I can take that out for now - but if it's okay to commit like this now then I will keep your tip in mind for next time and be sure to separate out the patches.

Comment 15

[Lukas Blakk [:lsblakk] use ?needinfo]

Attachment: Upgrade patch - Unittest Production 1.9 to Buildbot 0.7.7 - without a11y tests

This time I've left the timeout at the lower 60*5 and also, have left out a11y tests for now.

Comment 16

[Reed Loden [:reed]]

CVS HEAD:

Checking in tools/buildbot-configs/testing/unittest/master.cfg;
/cvsroot/mozilla/tools/buildbot-configs/testing/unittest/master.cfg,v  <--  master.cfg
new revision: 1.38; previous revision: 1.37
done
Checking in tools/buildbot-configs/testing/unittest/mozbuild.py;
/cvsroot/mozilla/tools/buildbot-configs/testing/unittest/mozbuild.py,v  <--  mozbuild.py
new revision: 1.24; previous revision: 1.23
done