Closed Bug 985022 (cvs-decom) Opened 6 years ago Closed 4 years ago
[tracker] Decommission cvs
There are blockers to this, but creating a tracker. Current users of cvs are: - Seamonkey - bugzilla - AUS3 The steps look something like: - check user list is complete - migrate users off cvs -- bugzilla is already enroute to git -- AUS3 will be replaced by Balrog, which is elsewhere. Can we migrate AUS3 sooner? -- Discuss future plans with Seamonkey project and support them to migrate elsewhere - make cvs read-only - decommission cvs
To be specific SeaMonkey uses CVS for releng needs (mozilla/tools iirc) and SEPERATELY for our website cvs-www (cvsroot=:www) from memory for seamonkeyproject-org. They are two seperate work items, but for a single project
A bunch of the old webtools still use CVS. Tinderbox, Bonsai, Doctor, Despot, etc. Bugzilla hasn't been actively using CVS for years. CVS is just a read-only mirror.
(In reply to Laura Thomson :laura from comment #0) > The steps look something like: ... > - decommission cvs - Update https://developer.mozilla.org/en-US/docs/Developer_Guide/Source_Code/CVS to redirect to the existing hg MDN pages.
Product: Release Engineering → Developer Services
Whiteboard: [kanban:engops:https://kanbanize.com/ctrl_board/6/136] → [kanban:engops:https://mozilla.kanbanize.com/ctrl_board/6/810] [kanban:engops:https://kanbanize.com/ctrl_board/6/136]
Whiteboard: [kanban:engops:https://mozilla.kanbanize.com/ctrl_board/6/810] [kanban:engops:https://kanbanize.com/ctrl_board/6/136] → [kanban:engops:https://mozilla.kanbanize.com/ctrl_board/6/810]
Tagging in some related hostnames as searchbait, since this bug took me a while. cvs1.dmz.scl3 cvs2.dmz.scl3 webtools2.dmz.scl3
aus3 is effectively dead. We're waiting to shut off machines, but we are definitely NOT doing any more code pushes, so the final steps of killing it no longer block killing CVS.
No longer depends on: diesnippets
So the question came up about what to do about cvs-mirror... The only reason I can think of to keep it around long term is for historical reference. For as often as it's likely to get used, I think perhaps making three tarballs, one of /cvsroot, one of /www, and one of /l10n, and placing those somewhere on ftp.mozilla.org would be a fine act of preservation. That way the data's not lost, and if someone actually has a need to look through it, they can download the tarball and set up a local copy to play with instead of us having to host it. We'd have to make sure to appropriately clean the CVSROOT module in each. (I think you get a "publicly-clean" copy when using the rsync module that pushes to cvs-mirror from cvs).
Status: I believe all production code for bugzilla and sea monkey has been moved off of cvs.m.o at this point. I'll set the entire site read-only on this Friday, April 17. I.e. this is final call, so setting need info on key folks.
Read-only is fine. We just had a Bugzilla 4.0 release today, but it should be the last one. I plan on sending out an official EOL notice for Bugzilla-on-cvs this week. What's the ETA on complete server tear-down?
(In reply to Hal Wine [:hwine] (use needinfo) from comment #7) > Status: I believe all production code for bugzilla and sea monkey has been > moved off of cvs.m.o at this point. > > I'll set the entire site read-only on this Friday, April 17. I.e. this is > final call, so setting need info on key folks. Read-only is fine for us as well, just as long as we can still access it to get some remaining files.
All cvs repositories on cvs.m.o are now in read-only mode. \o/
(In reply to Mark Côté [:mcote] from comment #8) > What's the ETA on complete server tear-down? As soon as practical. Data will be preserved, and cvs-mirror (anon r/o pserver access) will remain a bit longer. What's your concern or question behind the question? :)
No particular concern; was just wondering in case anyone asked me. :)
Component: Mercurial: hg.mozilla.org → General
QA Contact: hwine
Just clarifying, it's okay for cvs1 to be powered down. Bug can be closed after that.
ack. Currently in a change freeze, will work on the takedown of cvs1 after the thaw.
Nagios pulled in change 110127. 10.22.74.64 = cvs1.dmz.scl3 126.96.36.199 = cvs-rw-zlb.vips.scl3 Does have netvault, doesn't have NFS. Powered off, waiting to make sure there's no complaints before destroying fully (probably Monday the 23rd).
I've removed the backup jobs for cvs1.dmz.scl3.mozilla.com
Deleted extra DNS entries: dm-cvs01.mozilla.org CNAME cvs1.dmz.scl3.mozilla.com dm-cvs01.mozilla.org CNAME cvs.mozilla.org cvsserver.mozilla.org CNAME cvs.mozilla.org Deleted inventory, RHN, puppetdashboard. Zeus: ZLB Traffic Group: cvs.mozilla.org-rw ZLB Servers: cvs-rw-zlb.vips.scl3.mozilla.com:2401 (188.8.131.52) ZLB Pools: cvs-rw-2401 / 10.22.74.64:2401 ZLB Traffic Group: cvs.mozilla.org-rw-ssh ZLB Servers: cvs-rw-zlb.vips.scl3.mozilla.com:22 (184.108.40.206) ZLB Pools: cvs-rw-2401 / 10.22.74.64:22 Pulled from puppet in change 110634. Backups pulled in comment 16. Surprisingly, didn't spot any netops acls. Deleted from disk. Going to mark this R/F since I'm not seeing more work to this, but reopen if I've missed something.
Status: NEW → RESOLVED
Closed: 4 years ago
Resolution: --- → FIXED
Whiteboard: [kanban:engops:https://mozilla.kanbanize.com/ctrl_board/6/810] → [kanban:engops:https://mozilla.kanbanize.com/ctrl_board/6/810] [vm-delete:1]
Since it never got mentioned in the bug, and people looking for the archive might find this bug in their search to look for it, the archives of the CVS servers were placed at https://ftp.mozilla.org/pub/vcs-archive/
You need to log in before you can comment on or make changes to this bug.