Lightning is now being built fully on Thunderbird infrastructure and Thunderbird 17 is basically EOL. I propose we decommission the old calendar machinery, as it is not being used. Here are the machines I know of: momo-cal-master-01.vm.labs.scl3.mozilla.com momo-vm-cal-linux-01.vm.labs.scl3.mozilla.com momo-vm-cal-linux64-01.vm.labs.scl3.mozilla.com cal-mini-osx64-1.community.scl3.mozilla.com cal-vm-win32-1.community.scl3.mozilla.com Before you do this I'd like John to confirm and add any other machines I might have forgotten.
Moving to Server Ops. That these are VMs really only affects the final disposal at the very end; there's still a "any server" decom list. Once you have your final list, make sure it's clear what's going away and say "Yes, you can power off THESE machines." Thanks for the good housekeeping!
Assignee: server-ops-virtualization → server-ops
Component: Server Operations: Virtualization → Server Operations
QA Contact: dparsons → shyam
CC'ing gozer and C for the labs VMs.
Summary: Decomission calendar build machinery → Decommission calendar build machinery
In looking at machines for bug 946748, turned up another vm that looks like the same purpose/era as these... Was wondering if this should be included in the decom? cal-vm-win32-2.community.scl3.mozilla.com Thanks, CJK
Fine for me, I don't remember ever using this machine and I don't have access to that bug. I'll leave the final say to John again.
With Fallen's permission above, I have no objection to decomm'ing these: momo-cal-master-01.vm.labs.scl3.mozilla.com momo-vm-cal-linux-01.vm.labs.scl3.mozilla.com momo-vm-cal-linux64-01.vm.labs.scl3.mozilla.com cal-mini-osx64-1.community.scl3.mozilla.com cal-vm-win32-1.community.scl3.mozilla.com cal-vm-win32-2.community.scl3.mozilla.com Thanks =)
I'll take *.vm.labs.scl3.mozilla.com. Need to backup/archive anything ?
Powered off: - momo-cal-master-01.community.scl3.mozilla.com - momo-vm-cal-linux64-01.community.scl3.mozilla.com - momo-vm-cal-linux-01.community.scl3.mozilla.com
I don't think anything needs to be backuped, it should just be obsolete local buildbot config changes, the buildbot client and some build directories.
DNS entries for calendar-master.mozillalabs.com deleted.
I've just been made aware there is also cal-vm-tbox.community.scl3.mozilla.com. I don't think we have been using this machine at all, it can probably be deleted too.
cal-vm-win32-2.community.scl3.mozilla.com is not in inventory cal-mini-osx64-1.community.scl3.mozilla.com only contains PTR and A records nothing else. IP 184.108.40.206 and it's live. deleted these from inventory. cal-vm-win32-1.community.scl3.mozilla.com IP 220.127.116.11 machine stopped. A and PTR removed and deleted from inventory found a a cal-vm-win32-tbox in vmware - what is it and can it be decomissionned. https://inventory.mozilla.org/en-US/systems/show/527/
momo-cal-master-01.vm.labs.scl3.mozilla.com 10.22.112.142 removed A and PTR momo-vm-cal-linux64-01.community.scl3.mozilla.com 18.104.22.168 deleted the SREG momo-vm-cal-linux-01.community.scl3.mozilla.com 22.214.171.124 deleted A and PTR
(In reply to Ludovic Hirlimann [:Usul] from comment #11) > found a a cal-vm-win32-tbox in vmware - what is it and can it be > decomissionned. https://inventory.mozilla.org/en-US/systems/show/527/ I don't know what this is, but I assume its from the back and forth we had with the new windows vm. Fine by me to decommission. As before, gozer has the final word.
That's very very old, can get rid of it with prejudice.
Deleted vms, cleanup inventory.
Status: NEW → RESOLVED
Last Resolved: 4 years ago
Resolution: --- → FIXED
(In reply to Ludovic Hirlimann [:Usul] from comment #15) > Deleted vms, cleanup inventory. How many VMs and machines did we kill here? 3 each?
(In reply to Shyam Mani [:fox2mike] from comment #16) > (In reply to Ludovic Hirlimann [:Usul] from comment #15) > > Deleted vms, cleanup inventory. > > How many VMs and machines did we kill here? 3 each? 1 mac mini and 4/5 vms
Product: mozilla.org → mozilla.org Graveyard
You need to log in before you can comment on or make changes to this bug.