Closed Bug 771763 Opened 12 years ago Closed 12 years ago

Platform/Infra/config/migration blockers for Kuma launch

Categories

(Infrastructure & Operations Graveyard :: WebOps: Other, task)

x86_64
Linux
task
Not set
normal

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: openjck, Assigned: nmaul)

References

Details

We plan to launch the new MDN website (codenamed Kuma) on July 16, 2012. Before that happens, there are some unanswered questions that we need to consider. We do not have answers to these questions, but hope to figure them out with you.

1. Is there a launch checklist that we should be using?

2. The new platform currently lives on a server known as developer-new.mozilla.org. On July 16, will we be able to update the DNS record of developer.mozilla.org to point to this server? Any red flags we should watch out for?

3. Most content has been migrated from the old server (developer.mozilla.org) to the new server (developer-new.mozilla.org). There are some exceptions. For example, the Demo Studio (https://developer.mozilla.org/en-US/demos/) has not been migrated at all. We will need to look into moving this content over before the launch.

4. How much scheduled downtime do you expect? When do think we should schedule this downtime?

Development team: I made notes about the following topics, but I'm not sure what your questions are. Please fill those out for me.

5. Redirects?

6. Config changes?
Assignee: server-ops → server-ops-webops
(In reply to John Karahalis [:openjck] from comment #0)
> 1. Is there a launch checklist that we should be using?

Not that I'm aware of, but that's probably a good idea.

> 2. The new platform currently lives on a server known as
> developer-new.mozilla.org. On July 16, will we be able to update the DNS
> record of developer.mozilla.org to point to this server? Any red flags we
> should watch out for?

Yes, this would be a simple change. Actually, rather than change DNS we might opt to just change the backend pools that Zeus uses.

In either case, there are some settings that will need to be updated... various things (Kumascript, at least) point at "developer-new.mozilla.org". This should be part of the the checklist in #1.

> 3. Most content has been migrated from the old server
> (developer.mozilla.org) to the new server (developer-new.mozilla.org). There
> are some exceptions. For example, the Demo Studio
> (https://developer.mozilla.org/en-US/demos/) has not been migrated at all.
> We will need to look into moving this content over before the launch.

I'm not sure what all this entails. Bug 664724 may be relevant for Demo Studio itself, but I don't know if there's time to do that properly, or how it's been planned out. I don't know what else is missing either.

> 4. How much scheduled downtime do you expect? When do think we should
> schedule this downtime?

The downtime for cut-over should be minimal... less than 1 minute (likely only a few seconds).

> 5. Redirects?

Don't know of any... maybe something for Demo Studio and the like, depending on how we handle that.

> 6. Config changes?

All I know of for sure is the stuff in #2... basically changing a few things to refer to developer.mozilla.org rather than developer-new.mozilla.org, and offhand only one of those comes to mind (Kumascript).
Assignee: server-ops-webops → nmaul
(In reply to Jake Maul [:jakem] from comment #1)
 
> > 3. Most content has been migrated from the old server
> > (developer.mozilla.org) to the new server (developer-new.mozilla.org). There
> > are some exceptions. For example, the Demo Studio
> > (https://developer.mozilla.org/en-US/demos/) has not been migrated at all.
> > We will need to look into moving this content over before the launch.
> 
> I'm not sure what all this entails. Bug 664724 may be relevant for Demo
> Studio itself, but I don't know if there's time to do that properly, or how
> it's been planned out. I don't know what else is missing either.

Main thing, I think, is to dump the demo studio templates from mysql and import them to -new. There might be some issues with discrepancies between user accounts, but I haven't had time to think that through.

Either way, we can't cut over without an update from current demo studio. 

luke/james: Maybe django dump data / load data can help us here? natural keys and all that?
Depends on: 773381
Blocks: 770383
Blocks: 756263
No longer blocks: 770383
Summary: Research: Kuma launch on July 16, 2012 → Platform/Infra/config/migration blockers for Kuma launch
Depends on: 710713
Depends on: 762252
Depends on: 771814
Depends on: 772468
Depends on: 763498
Depends on: 773505
Depends on: 773638
No longer depends on: 710713
No longer depends on: 771814
Depends on: 770699
Depends on: 770732
Depends on: 771041
Depends on: 771640
Depends on: 773285
No longer depends on: 773638
Depends on: 773779
Depends on: 773815
Depends on: 711477
Depends on: 768524
Depends on: mdn-attachments
Depends on: 659371
No longer depends on: 771041
Depends on: 774472
Depends on: 776123
Depends on: 776248
Depends on: 776739
Depends on: 774501
Depends on: 775241
Depends on: 775352
Depends on: 775747
Depends on: 776130
No longer depends on: 776248
No longer depends on: 775352
Depends on: 779304
No longer depends on: mdn-attachments
Don't need this bug anymore, I think... closing!

Congrats on the successful launch. :)
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → FIXED
Component: Server Operations: Web Operations → WebOps: Other
Product: mozilla.org → Infrastructure & Operations
Product: Infrastructure & Operations → Infrastructure & Operations Graveyard
You need to log in before you can comment on or make changes to this bug.