946303 - Please re-image 2 Lion try build slaves as Mavericks testers

Status: RESOLVED FIXED

(Infrastructure & Operations :: RelOps: General, task)

Description

[Chris Cooper [:coop] (he/him)]

I've set aside the following Lion try build slaves for conversion to Mavericks:

* bld-lion-r5-039
* bld-lion-r5-040

This should help us iterate more quickly on fixing the test failures on Mavericks, allowing us to stop testing on 10.8 entirely even sooner.

Comment 1

[Dustin J. Mitchell [:dustin] (he/him)]

This could be a little tricky since puppet doesn't yet support mavericks.  I was hoping puppetlabs would get their act together before we needed it, but it was not to be.

I can probably hack these two together the way I did the others - it may just take a bit.

Comment 2

[Amy Rich [:arr] [:arich]]

We should pull down the release version of Mavericks instead of the seed, too, obviously.

Comment 3

[Dustin J. Mitchell [:dustin] (he/him)]

bld-lion-r5-039 -> t-mavericks-r5-002.test.releng.scl3.mozilla.com
bld-lion-r5-040 -> t-mavericks-r5-003.test.releng.scl3.mozilla.com
https://etherpad.mozilla.org/jHUDuqyQlF

Comment 4

[Dustin J. Mitchell [:dustin] (he/him)]

We don't have any base image for mavericks - we lost the seed when I torched the deploystudio host :(

Building the base image will require:
 * a Mavericks final image
 * VMware fusion or a spare mini with two drives
 * https://mana.mozilla.org/wiki/display/SYSADMIN/Bootable+OS+X+10.9+Maverick
 * Installing to the second drive, then capturing that with Disk Utility
I won't have a chance to work on this for a while - probably next quarter.  If someone else does some of the above, that would help ;)

Comment 5

[Chris Cooper [:coop] (he/him)]

(In reply to Dustin J. Mitchell [:dustin] (I read my bugmail; don't needinfo me) from comment #3)
> bld-lion-r5-039 -> t-mavericks-r5-002.test.releng.scl3.mozilla.com
> bld-lion-r5-040 -> t-mavericks-r5-003.test.releng.scl3.mozilla.com
> https://etherpad.mozilla.org/jHUDuqyQlF

If we're not going to move on this until January, it would have been nice to keep those two try slaves around until we're ready to re-image. Any chance we can bring them back until we're ready to deploy Mavericks on them?

Comment 6

[Amy Rich [:arr] [:arich]]

With only one week left, it's unlikely that relops+dcops is going get to this even to switch things back because there are so many things creating a time crunch for the end of the quarter and the mtv1 move.  We didn't realize that you weren't actually ready to have these machines removed form the build pool yet if we weren't going to get to reimaging them right away.  If it's critical that they be reimaged and added back to the build pool, please let us know, and we'll try to get to it before the company closes.

Comment 7

[Chris Cooper [:coop] (he/him)]

(In reply to Amy Rich [:arich] [:arr] from comment #6)
> With only one week left, it's unlikely that relops+dcops is going get to
> this even to switch things back because there are so many things creating a
> time crunch for the end of the quarter and the mtv1 move.  We didn't realize
> that you weren't actually ready to have these machines removed form the
> build pool yet if we weren't going to get to reimaging them right away.  If
> it's critical that they be reimaged and added back to the build pool, please
> let us know, and we'll try to get to it before the company closes.

I just don't want half-measures. Now we have two slaves that will be doing *nothing* for a month.

Comment 8

[Dustin J. Mitchell [:dustin] (he/him)]

I got an image together using VMware Fusion, and I'm trying to restore it.  If I set it to "first disk available", Deploystudio is running `asr restore` without the --erase flag, which is causing "File copy is not supported anymore.  Use the --erase flag" and an abort of the install.  If I set it to restore to /dev/disk0s2, it says the device is too small.  The latter is the config for the other r5 (mountain lion) configs.

This is because these are re-purposed R5 builders.  Builders run their two disks with RAID, while testers leave the second disk unused.

I deleted the RAID set in Disk Utility and re-ran the workflow, and that seemed to get past this particular issue.  Jake, is there an automatic way to delete RAID?

Comment 9

[Dustin J. Mitchell [:dustin] (he/him)]

Well, I'll be damned.  That worked.  The hosts are up and yours to play with, Coop.  I'll leave this open to get Jake's help with the RAID question.

Comment 10

[Jake Watkins [:dividehex]]

(In reply to Dustin J. Mitchell [:dustin] (I ignore NEEDINFO) from comment #8)
> I got an image together using VMware Fusion, and I'm trying to restore it. 
> If I set it to "first disk available", Deploystudio is running `asr restore`
> without the --erase flag, which is causing "File copy is not supported
> anymore.  Use the --erase flag" and an abort of the install.  If I set it to
> restore to /dev/disk0s2, it says the device is too small.  The latter is the
> config for the other r5 (mountain lion) configs.
> 
> This is because these are re-purposed R5 builders.  Builders run their two
> disks with RAID, while testers leave the second disk unused.
> 
> I deleted the RAID set in Disk Utility and re-ran the workflow, and that
> seemed to get past this particular issue.  Jake, is there an automatic way
> to delete RAID?

Yes, this can be done with a DS script task using diskutil.  We can do the same thing with casper when the time comes.

Comment 11

[Dustin J. Mitchell [:dustin] (he/him)]

Awesome.  We'll wait until the deployment starts to see which of those options we need to use.