Closed Bug 543517 Opened 15 years ago Closed 14 years ago

[Tracking Bug] Move ~40 minis from MPT to 650castro

Categories

(mozilla.org Graveyard :: Server Operations: Projects, task)

Product:
mozilla.org Graveyard
Component:
Server Operations: Projects
Platform:
x86
All
Type:
task
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED INVALID

People

(Reporter: joduinn, Assigned: phong)

Details

We need to reduce the space in MPT by 1st March 2010. This will mean moving ~40minis out of MPT. For now the only place they can go is into 650castro. This bug is to track which machines need to be moved, installing shelves, tweaking configs, etc. We may be able to avoid a downtime, depending on which machines are being moved, and how long they will be offline, but still TBD.
mrz/oremj: what specific minis did you need moved? Can you list their names here, so we can start planning on our side?
(In reply to comment #1) > mrz/oremj: what specific minis did you need moved? Can you list their names > here, so we can start planning on our side? Jeremy, can you give me the list of machines which are in rack: 103.01 103.02 103.05 I dont have access to this in inventory, and according to Phong, these are the racks that need to be emptied. Once we have the machine names, please assign back, so RelEng can figure out a transition plan. Hopefully we can move a few at a time, without any downtimes, but it depends on what machines are involved.
Assignee: nobody → jeremy.orem+bugs
Component: Release Engineering → Server Operations
QA Contact: release → mrz
https://public.inventory.mozilla.org/systems/racks/
Assignee: jeremy.orem+bugs → joduinn
(In reply to comment #3) > https://public.inventory.mozilla.org/systems/racks/ Cool, thanks Jeremy. RelEng machines to be moved, listed by rack: talos-rev2-linux15 try-mac-slave10 try-mac-slave11 try-mac-slave12 try-mac-slave13 try-mac-slave14 try-mac-slave15 try-mac-slave16 try-mac-slave17 try-mac-slave18 try-mac-slave19 qm-pxp-try05 qm-pxp-try06 qm-pubuntu-try07 talos-rev2-linux14 talos-rev2-vista15 qm-pubuntu-try09 talos-rev2-vista13 moz2-darwin9-slave18 moz2-darwin9-slave17 moz2-darwin9-slave11 moz2-darwin9-slave12 moz2-darwin9-slave13 moz2-darwin9-slave14 moz2-darwin9-slave15 moz2-darwin9-slave16 qm-pubuntu-try08 bm-xserve21 fx-mac-1.9-slave2 bm-xserve11 bm-xserve12 bm-xserve20 qm-pubuntu-try05 qm-pubuntu-try06 qm-pvista-try05 qm-pvista-try06 qm-pleopard-try05 qm-pleopard-try06 moz2-darwin9-slave10 moz2-darwin9-slave09 qm-pvista-try10 qm-pvista-try11 qm-pxp-try08 qm-pleopard-try08 qm-pleopard-try09 qm-pleopard-try10 qm-pleopard-try11 qm-pubuntu-try10 bm-mini-build-ref qm-pubuntu-try11 talos-rev2-leopard08 talos-rev2-leopard09 talos-rev1-leopard02.mv qm-rhel03 qm-pmac01 qm-pmac02 moz2-darwin9-slave23 try-mac-slave09 talos-rev1-win701 qm-mini-centos01 qm-mini-centos02 qm-vmware02 talos-rev1-xp02.mv talos-rev1-vista02.mv moz2-darwin9-slave21 talos-rev1-xp01.mv moz2-darwin9-slave24 moz2-darwin9-slave25 try-mac-slave08 moz2-darwin9-slave26 talos-rev2-xp21 qm-pxp-try07 talos-rev2-linux17 qm-stage-w2k3-01 SPARE-bm-stage-osx-01 talos-rev1-vista01.mv moz2-darwin9-slave19 moz2-darwin9-slave20 try-mac-slave07 talos-rev1-leopard01.mv moz2-darwin9-slave22 try-mac-slave06 talos-rev1-linux05 When possible, I'll coord with IT to bring back a few every time they visit MPT. Done gradually like that, we should be able to avoid downtimes, I believe.
Phong: is there shelving ready for these minis in 650castro? Once there is shelving, we can coord taking down some of these with each MPT colo visit.
Assignee: joduinn → phong
ps: I cant set the "colo-trip" flag, but this bug does need "colo-trip"!
The shelving is (In reply to comment #5) > Phong: is there shelving ready for these minis in 650castro? > > Once there is shelving, we can coord taking down some of these with each MPT > colo visit. The minis at MPT are sitting on shelves that will also relocate to 650. John - there's no reason to start scheduling this right now. CoreSite hasn't gotten their act together and the clock hasn't even begun. If Layer42 works out I'd rather move them there first than to 650 and then Layer42. Can we hold on this until we have more data?
Component: Server Operations → Server Operations: Projects
(In reply to comment #7) > The shelving is (In reply to comment #5) > > Phong: is there shelving ready for these minis in 650castro? > > > > Once there is shelving, we can coord taking down some of these with each MPT > > colo visit. > > The minis at MPT are sitting on shelves that will also relocate to 650. > > John - there's no reason to start scheduling this right now. CoreSite hasn't > gotten their act together and the clock hasn't even begun. If Layer42 works > out I'd rather move them there first than to 650 and then Layer42. > > Can we hold on this until we have more data? Sure. I was worried about the deadline of 1st March in comment#0, but if thats changed, then I'm less concerned. Just let me know when you have the revised deadline, and we'll work backwards from that.
(In reply to comment #8) > (In reply to comment #7) > > The shelving is (In reply to comment #5) > > > Phong: is there shelving ready for these minis in 650castro? > > > > > > Once there is shelving, we can coord taking down some of these with each MPT > > > colo visit. > > > > The minis at MPT are sitting on shelves that will also relocate to 650. > > > > John - there's no reason to start scheduling this right now. CoreSite hasn't > > gotten their act together and the clock hasn't even begun. If Layer42 works > > out I'd rather move them there first than to 650 and then Layer42. > > > > Can we hold on this until we have more data? > > Sure. I was worried about the deadline of 1st March in comment#0, but if thats > changed, then I'm less concerned. > > Just let me know when you have the revised deadline, and we'll work backwards > from that. Today is 1st March, so there goes the original deadline. Any revised date?
Nope, none.
This is probably invalid now since we've rebuilt a lot of these already. Do we still need this around?
Status: NEW → RESOLVED
Closed: 14 years ago
Resolution: --- → INVALID
Product: mozilla.org → mozilla.org Graveyard
You need to log in before you can comment on or make changes to this bug.