In bug#463325, we mothballed FF2 talos machines that were no longer being used. Some of these FF talos machines are not of the right spec to be used for moz2 talos. However we could use these in the build/unittest pool-of-slaves. There is nothing to backup/save from these machines. Please take the refimage at qm-moz2mini01, and use it to reimage all 4 of these machines: qm-mini-ubuntu04 qm-mini-vista04 qm-mini-xp04 qm-pmac04 Looking at inventory, I believe these should be renamed to: moz2-darwin9-slave09 moz2-darwin9-slave10 moz2-darwin9-slave11 moz2-darwin9-slave12

While you are at it, can you also reimage moz2-darwin9-slave01, making it identical to the new moz2-darwin9-slave09/10/11/12? We've just realised its quite out-of-date, and needs to be reimaged also. There is nothing to backup, and its not being used, so feel free to reimage whenever you are ready.

moz2-darwin9-slave01 has been re-imaged.

Phong: please reassign back to releng when the re-imaging is done so we can get these setup as slaves.

I am having some problem re-imaging these. It is complaining that the drive is not big enough for the image. I will see what I can do about that.

(In reply to comment #4) > *** Bug 482184 has been marked as a duplicate of this bug. *** (In reply to comment #3) > *** Bug 482185 has been marked as a duplicate of this bug. *** Coop, yep, bug#482184 is a dup. However, I think 482185 is not a dup. Personally, I've typically found it less confusing to file two bugs for this kinda work: one for the IT part of the work (cloning/imaging, dns, etc) and one for the RelEng part of the work (installing buildbot, testing on staging, moving to production). Does that make sense?

(In reply to comment #6) > I am having some problem re-imaging these. It is complaining that the drive is > not big enough for the image. I will see what I can do about that. Strange - I thought all those mac minis came with the same size disk. Let us know what you find out!

(In reply to comment #7) > Coop, yep, bug#482184 is a dup. However, I think 482185 is not a dup. > Personally, I've typically found it less confusing to file two bugs for this > kinda work: one for the IT part of the work (cloning/imaging, dns, etc) and one > for the RelEng part of the work (installing buildbot, testing on staging, > moving to production). I have no problem with having separate bugs, but we need to get better at creating bugs with accurate summaries/initial comments/dependencies. As it stands right now, this bug seems to cover both aspects which is why I duped as I did.

(In reply to comment #8) > (In reply to comment #6) > > I am having some problem re-imaging these. It is complaining that the drive is > > not big enough for the image. I will see what I can do about that. > > Strange - I thought all those mac minis came with the same size disk. Let us > know what you find out! The older mac minis have 60GB drives and the newer minis have 80GB drives. I was able to re-image these using a different method. They will be online this afternoon.

re-imaged and updated in inventory. moz2-darwin9-slave09 IN A 10.2.71.141 moz2-darwin9-slave10 IN A 10.2.71.142 moz2-darwin9-slave11 IN A 10.2.71.228 moz2-darwin9-slave12 IN A 10.2.71.229

Thanks Phong.

(In reply to comment #10) > (In reply to comment #8) > > (In reply to comment #6) > > > I am having some problem re-imaging these. It is complaining that the drive is > > > not big enough for the image. I will see what I can do about that. > > > > Strange - I thought all those mac minis came with the same size disk. Let us > > know what you find out! > > The older mac minis have 60GB drives and the newer minis have 80GB drives. I > was able to re-image these using a different method. They will be online this > afternoon. Ah, good to know, that was news to me. And thanks Phong for the imaging work, too!

(In reply to comment #14) > https://wiki.mozilla.org/ReleaseEngineering:BuildbotMasterChanges ignore this. copy/paste fail.

Where do we want these 4 machines to go end up ? Someone mentioned try server I think, currently we have 4 of each platform there but recently unit tests.

... where enabled.

This adds the four machines from this bug, plus bm-xserve12 from bug 474544, to staging for testing.

Comment on attachment 371373 [details] [diff] [review] Add new machines to staging committed changeset 1076:d081ec96a3a4 and staging-master reconfig'd.

moz2-darwin9-slave11 and 12 are connected to staging-master:moz2-master for testing; still need restart-buildbot-on-boot.

I ended up hooking these machines up to the try master - I may as well see the rest of it through.

try-mac-slave08 is set to autologin and start buildbot now. The other three are currently running unittests - I'll get them shortly.

Alright, 06, 07, 08 and 09 have start-on-boot installed and are in the try pool. The only thing left to do here is fix the slave name in buildbot.tac on 06 to be 'mac6'. I'll do that tomorrow after it becomes idle.

These machines have mercurial 1.2.1 (instead of 0.9.5 of the older builders). Bug 488580 for the general upgrade.

Can't think of anything else that needs doing here, now that the builders are connected to the try master. Just need the DNS records fixed in the dep bug.

DNS looks fixed now: [bhearsum@cm-vpn01 ~]$ host try-mac-slave06 try-mac-slave06.mozilla.org has address 10.2.76.95 [bhearsum@cm-vpn01 ~]$ host try-mac-slave07 try-mac-slave07.mozilla.org has address 10.2.76.96 [bhearsum@cm-vpn01 ~]$ host try-mac-slave08 try-mac-slave08.mozilla.org has address 10.2.76.97 [bhearsum@cm-vpn01 ~]$ host try-mac-slave09 try-mac-slave09.mozilla.org has address 10.2.76.98 I got slave06 connected to the try master with the proper name, too.