Closed Bug 394069 Opened 12 years ago Closed 8 years ago

migration of stage.m.o/ftp.m.o

Categories

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

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: joduinn, Assigned: justdave)

References

Details

Tracking bug for Q3 goal. Build need to work with IT to:

# stage.m.o/ftp.m.o migration/enhancement completion
# automatic virus scan of all bits before they're publicly visible. 
# automatic disk cleanup to avoid emergency firedrills when we are out of space
OS: Mac OS X → All
Hardware: PC → All
Q3 goal, so upgrading severity
Severity: normal → major
Priority: -- → P3
Depends on: 396594
Depends on: 397541
Depends on: 397876
Depends on: 360397
Depends on: 399765
Depends on: 399848
dm-stage01 and dm-stage02 are both open for business (testing anyway) as of yesterday.  cf has a testing tinderbox pointed at dm-stage02 now, and we'll see how it works over the next couple days before opening it to the general stage audience.  dm-stage02 is the accessible box, dm-stage01 is the one with write-access to the netapp.
Assignee: build → nobody
QA Contact: mozpreed → build
Depends on: 400984
Depends on: 403023
new kernel looks good, no crashes.  I'd like to get this done next week - what needs to be done before we make the hard cut?  
(In reply to comment #3)
> new kernel looks good, no crashes.  I'd like to get this done next week - what
> needs to be done before we make the hard cut?  

heh, not.  Not back then anyway.  See bug 402754 for the interim details.  But it's looking like we might be ready now.  We'll know if a few more days.

Anyhow, here's the current plan:

1) We need to copy the ssh host keys over from surf to avoid disruptions for
things that use the stage.mozilla.org domain name.

2) surf will continue to be available via stage-old.mozilla.org for at least a
few weeks after we switch as a fallback in case anyone runs into a critical
problem that we can't solve immediately after we switch

3) DNS for stage.mozilla.org will be changed to point at dm-stage02 instead of
surf on the cutover date.

That's the basic plan, assuming all goes well.  Changing host keys will involve
tinderbox intervention for anyone that's already talking to stage-new.
Depends on: 72410
No longer depends on: 403023
No longer depends on: 342972
The enhancement dependencies off this bug that don't block the migration are being moved to bug 419978.
Summary: migration & enhancement of stage.m.o/ftp.m.o → migration of stage.m.o/ftp.m.o
No longer blocks: 398148
Depends on: 398148
Blocks: 72410
No longer depends on: 72410
Depends on: 422198
Depends on: 421917
No longer depends on: 398148
Depends on: 422733
Future'd while waiting on bug 402754.
Component: Release Engineering → Release Engineering: Future
QA Contact: build → release
This is mine, for the time being.
Component: Release Engineering: Future → Server Operations: Projects
QA Contact: release → justin
Assignee: nobody → justdave
Current status:

unionfs is now supported on RHEL5 (it wasn't when we started), and FC7 (current OS on the staging servers) has been EOLed.  Next plan of action is to reload both dm-stage01 and 02 with RHEL5 and try again from there.  With RHEL5 being a more-stable kernel in general, it's possible some of this may clear up.  I'll get an additional bug filed for the reloads shortly.

Some stuff on dm-stage01 is going to have to move back to surf in the meantime.
Changing QA Contact.
QA Contact: justin → mrz
Grabbing as a Q1 goal.
Priority: P3 → P1
No longer depends on: 446401
closing this out..  Not sure it is relevant anymore.  We will be rebuilding a lot of the ftp infra when we move it to SCL3 soon, but that will be a new set of bugs.
Status: NEW → RESOLVED
Closed: 8 years ago
Resolution: --- → FIXED
Product: mozilla.org → mozilla.org Graveyard
You need to log in before you can comment on or make changes to this bug.