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)
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 | ||
Updated•12 years ago
|
Assignee: server-ops → nmaul
Assignee | ||
Comment 1•12 years ago
|
||
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. :)
Assignee | ||
Comment 2•12 years ago
|
||
Per rhelmer, things are looking good so far and we're hoping to deploy this around 6/27, +/- 1 day.
Comment 3•12 years ago
|
||
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.
Comment 4•12 years ago
|
||
I see 6/27 +/- 1 day, so wanted to see if a deployment date has been decided.
Assignee | ||
Comment 5•12 years ago
|
||
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.
Assignee | ||
Comment 6•12 years ago
|
||
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
Updated•11 years ago
|
Component: Server Operations: Web Operations → WebOps: Other
Product: mozilla.org → Infrastructure & Operations
Updated•6 years ago
|
Product: Infrastructure & Operations → Infrastructure & Operations Graveyard
You need to log in
before you can comment on or make changes to this bug.
Description
•