Closed Bug 766213 Opened 12 years ago Closed 12 years ago

deploy new browserid etherpad site on etherpadadm/etherpad2.webapp

Categories

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

All
Other
task
Not set
normal

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: nmaul, Assigned: nmaul)

Details

This previously lived on the now-broken etherpad-dev seamicro atom node. We're just going to deploy it in its new/final home, etherpad2.webapp.phx1.mozilla.com. However this should be done through the (new) admin node, like we normally do.

There was a seamicro admin node previously... need to port it's puppet configs and /data/ to the new admin node.
Assignee: server-ops → nmaul
This is completed.

In order to make this the production site, we'll need to:

0) Wait for the green light from rhelmer, who's leading some QA/testing on the browserid codebase. :)

1) Add a GRANT to the new user to access the old/live database. Can be done anytime.

2) Stop etherpad on the new node.

3) Make a fresh DB dump on the slave server, for backup purposes.

4) Change the DB name in the config etherpad.local.properties config file, deployed by puppet. Absolutely do not do until it's time to switch- the new code will DROP columns in the existing database and it will no longer be possible to *not* use browserid without doing a DB restore.

5) Deactivate the old node (etherpad1) in the etherpad:9000 pool in Zeus, and stop etherpad on that server.

5) Start etherpad on the new node (etherpad2).

6) Activate the new node (etherpad2) in the etherpad:9000 pool in Zeus.

7) Prepare for complaints- some 3rd parties use etherpad, and may be surprised/unhappy about being forced into browserid. I suggest having a stock reply ready to go, with info on why browserid is better than local accounts. :)
Per rhelmer, things are looking good so far and we're hoping to deploy this around 6/27, +/- 1 day.
One reason we're waiting until next week is to give time to announce this at the Monday meeting, and give a few days for people to find show-stoppers. Technically I think we're ready to go any time.
 I see 6/27 +/- 1 day, so wanted to see if a deployment date has been decided.
This is scheduled for today at 5:30pm PT. Announcement has been made via Yammer, email, and @MozillaIT's twitter account.

#1 above is completed. The rest will be done closer to the actual maintenance time.

Also, I can send a message to everyone who's using Etherpad through the admin interface slightly before the maintenance happens. I'll do that around 5pm.
This maintenance is completed!

A backup of the original database exists on the slave DB server if needed, and the old server (with the old codebase) is still alive for now, in case we need an emergency roll-back... that would be troublesome though, as any new data from now forward would be lost... better to roll-forward if we can. :)
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.