upgrade ubuntu testers to puppet-3.2.0

RESOLVED FIXED

Status

RESOLVED FIXED
5 years ago
5 years ago

People

(Reporter: dustin, Assigned: rail)

Tracking

Details

(Whiteboard: [buildduty])

The per-host process for this is pretty simple, and does not require a reimage.  I just need to coordinate with buildduty so I'm not doing it while tests are running.
talos-linux32-ix-* are finished.  I'll knock out linux64 tomorrow.  It's just a lot of SSHing..

Rail, how should we handle this for AWS?
Flags: needinfo?(rail)
I think the best approach would be creating new slaves from scratch, so they don't even touch old puppet. In this case we eliminate a chance of possible problems with future slave creation not on top of the existing puppetized base.

Dustin, what are the commands I should be run on a fresh slave? I assume something like:

hg clone puppet320_repo
export something
./puppetize.sh
Flags: needinfo?(rail)
wget -O puppetize.sh http://hg.mozilla.org/users/dmitchell_mozilla.com/puppet320/raw-file/tip/modules/puppet/files/puppetize.sh
PUPPET_SERVER=releng-puppet2.srv.releng.use1.mozilla.com ./puppetize.sh
puppet agent --test --server=releng-puppet2.srv.releng.use1.mozilla.com
puppet agent --test

(it will work with any puppet master, but using a closer master saves bandwidth costs)
OK, all of talos-linux64-ix-* are finished, except 004, which is currently loaned.  I'm going to temporarily modify the kickstart process to use 3.2.1, too.
Rather than modify the kickstart process, I changed the puppet CNAME in test.releng.scl3.mozilla.com to point to releng-puppet2.srv.releng.scl3.mozilla.com.  Puppetize.sh will still install 2.7.17, but that should get upgraded during the puppetize.sh run.
Er, scratch that.  Kickstarting will continue to install 2.7.17 until this is done.
Assignee: dustin → rail
Depends on: 882821
Depends on: 882862
Depends on: 883115
tst-linux{32,64}-ec2-0{01..29} (us-east-1) and tst-linux{32,64}-ec2-3{01..29} (us-west-2) are live. ~120 in total.

I'll migrate the rest soon, maybe on the weekend.
Done. 

We'll need to figure out a new procedure for loaners. Slaves have to be in DNS (A+PTR) before we can puppetize them.
Status: NEW → RESOLVED
Last Resolved: 5 years ago
Resolution: --- → FIXED
Looks like talos-linux64-ix-009.test.releng.scl3.mozilla.com got missed, too - it's still hitting the old masters.  I fixed it up.
Component: Server Operations: RelEng → RelOps
Product: mozilla.org → Infrastructure & Operations
You need to log in before you can comment on or make changes to this bug.