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
5 years ago
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?
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
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?
er, or will turn into webapps. Maybe I shouldn't type when so tired. :D
(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.
(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.
Split out into service specific bugs.
Status: NEW → RESOLVED
Last Resolved: 5 years ago
Resolution: --- → WORKSFORME
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.