849037 - Create VMs to replace kvm-based VMs

Status: RESOLVED WORKSFORME

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

Description

[John O'Duinn [:joduinn] (please use "needinfo?" flag)]

From bug#846332, here's a list of VMs that need to be moved from KVM. Filing to track creating non-KVM-based VMs. 

NOTE: Work that involves touching these VMs need to be coordinated with RelEng buildduty, to avoid impacting any production use.


> claimed by RelEng, moving from kvm to ESX:
> ==========================================
> signing1.build.scl1.mozilla.com
> signing2.build.scl1.mozilla.com
> signing3.srv.releng.scl3.mozilla.com
> slavealloc.build.scl1.mozilla.com
> buildapi01.build.scl1.mozilla.com
> redis01.build.scl1.mozilla.com
> releng-puppet1.build.mtv1.mozilla.com
> releng-puppet1.build.scl1.mozilla.com
> master-puppet1.build.scl1.mozilla.com
> scl-production-puppet.build.scl1.mozilla.com
> scl3-production-puppet.srv.releng.scl3.mozilla.com
> staging-puppet.srv.releng.scl3.mozilla.com

Comment 1

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

We need to split this out based on service since the requirements and migration plan is different based on use case.  Also, releng-puppet1.build.mtv1.mozilla.com will die with mtv1; there is no intention to replace it.  It's also unlikely that we would replace puppet hosts in scl1 since they already have counterparts in scl3 where vmware is located.

So the total list of bugs to replace this on is:

1) signing servers (we will need some discussion about datacenter redundancy in this bug as well)
signing1.build.scl1.mozilla.com
signing2.build.scl1.mozilla.com
signing3.srv.releng.scl3.mozilla.com

2) slavealloc.build.scl1.mozilla.com

3) buildapi01.build.scl1.mozilla.com

4) redis01.build.scl1.mozilla.com

5) scl3-production-puppet.srv.releng.scl3.mozilla.com

6) master-puppet1.build.scl1.mozilla.com (assuming you want to keep a separate puppet master just for buildbot masters, if not, then we don't need a replacement).

7) staging-puppet.srv.releng.scl3.mozilla.com (assuming you want to keep a separate puppet master just for staging slaves, if not, then we don't need a replacement).

Are #6 and #7 required or will we lump those into the puppet master in scl3?

Comment 2

[Chris AtLee [:catlee]]

6) is also used for other misc. server like things like the signing servers, buildapi, redis. so we'll need to migrate all those over to puppetagain, or spin up a puppetthefirstorsecondtime master in scl3

7) can probably go away

Comment 3

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

catlee: the three specific things you mention will be moving out of scl1 entirely so will probably migrate to puppetagain in scl3 (or will not turn into webapp things that won't be either).  I thought master-puppet1 was used for things like buildbot masters?

Comment 4

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

er, or will turn into webapps.  Maybe I shouldn't type when so tired.  :D

Comment 5

[Chris AtLee [:catlee]]

(In reply to Amy Rich [:arich] [:arr] from comment #3)
> catlee: the three specific things you mention will be moving out of scl1
> entirely so will probably migrate to puppetagain in scl3 (or will not turn
> into webapp things that won't be either).  I thought master-puppet1 was used
> for things like buildbot masters?

It's also used for buildbot masters. The complete list of hosts managed by this master is here:
http://hg.mozilla.org/build/puppet-manifests/file/8360fe32b929/buildmaster-production.pp

So it's buildbot masters, signing servers, redis, buildapi, releng-mirror01, dev-master01.

Comment 6

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

(In reply to Amy Rich [:arich] [:arr] from comment #1)
> 7) staging-puppet.srv.releng.scl3.mozilla.com (assuming you want to keep a
> separate puppet master just for staging slaves, if not, then we don't need a
> replacement).

Agree with catlee that this can go away. I think he covered everything else.

Comment 7

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

Split out into service specific bugs.