656245 - Make sure that all dev/pp slaves are listed in staging.pp

Status: RESOLVED FIXED

(Release Engineering :: General, defect, P2)

Description

[Rail Aliiev [:rail]]

While playing with puppet master today I realized that some of the servers listed as "dev/pp" are connected to production-puppet master and not listed in staging.pp. Actually the host I was playing with were old preproduction machines which were supposed to behave like production ones. ATM we use dev machines for both dev and pp, so it would be great to sync the list.

Comment 1

[Rail Aliiev [:rail]]

The list of slaves listed in slavealloc as dev/pp but not listed in staging.pp:

1) Old preproduction slaves (*10). They should be listed in staging.pp (at least builders) to pick up a proper config for purge_builds.py.
moz2-darwin10-slave10
moz2-darwin9-slave10
moz2-linux-slave10
moz2-linux64-slave10
talos-r3-fed-010
talos-r3-fed64-010
talos-r3-leopard-010
talos-r3-snow-010

2) linux64-ix. 01, 02 numbers looks like good candidates for staging, 37 as a testing before to move back to production.
linux64-ix-slave01
linux64-ix-slave02
linux64-ix-slave37

3) random? testing before moving to production?
talos-r3-snow-003
bm-xserve21
linux-hgwriter-slave01
linux-hgwriter-slave02
linux-hgwriter-slave03
linux-hgwriter-slave04

I know what to do with 1) (see the patch), but not sure what to do with 2) and 3).

Comment 2

[Rail Aliiev [:rail]]

Attachment: Move old preproduction slaves to staging.pp

Comment 3

[Rail Aliiev [:rail]]

Comment on attachment 531881 [details] [diff] [review]
Move old preproduction slaves to staging.pp

http://hg.mozilla.org/build/puppet-manifests/rev/2c46a4e15d09

Comment 4

[Rail Aliiev [:rail]]

Attachment: Use ${level}

Hmm, looks like I missed two things.

1) I shouldn't have removed the hosts from mpt-production.pp. I should have changed "inherits". It's needed the first time to distribute proper puppet cofigs.

2) Looks like it's better to use ${level} as a file extension, because ${configExt} is used only once.

To be tested.

Comment 5

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

(In reply to comment #4)
> Created attachment 531996 [details] [diff] [review] [review]
> Use ${level}
> 
> Hmm, looks like I missed two things.
> 
> 1) I shouldn't have removed the hosts from mpt-production.pp. I should have
> changed "inherits". It's needed the first time to distribute proper puppet
> cofigs.

Meh, I've never seen this work correctly, but yes.

> 2) Looks like it's better to use ${level} as a file extension, because
> ${configExt} is used only once.

Makes sense to me

Comment 6

[Rail Aliiev [:rail]]

Attachment: Use ${level}

Tested in staging. I only added a dot before ${level}
First time setup by puppet + automatic reboot seen as well.

Comment 7

[Rail Aliiev [:rail]]

Comment on attachment 532562 [details] [diff] [review]
Use ${level}

http://hg.mozilla.org/build/puppet-manifests/rev/d69be018d952

Comment 8

[Rail Aliiev [:rail]]

Deployed the changes on all masters.

The following slaves are still not listed in staging.pp:

2) linux64-ix. 01, 02 numbers looks like good candidates for staging, 37 as a testing before to move back to production.
linux64-ix-slave01
linux64-ix-slave02
linux64-ix-slave37

3) random? testing before moving to production?
talos-r3-snow-003
bm-xserve21
linux-hgwriter-slave01
linux-hgwriter-slave02
linux-hgwriter-slave03
linux-hgwriter-slave04