Last Comment Bug 550510 - Upgrade production Bouncer to Tuxedo
: Upgrade production Bouncer to Tuxedo
04/28/2010 5:00pm PDT
Product: Graveyard
Classification: Graveyard
Component: Server Operations (show other bugs)
: other
: All Other
: -- normal (vote)
: ---
Assigned To: Jeremy Orem [:oremj]
: matthew zeier [:mrz]
Depends on: 558729 563619
Blocks: 372746 394498
  Show dependency treegraph
Reported: 2010-03-05 10:24 PST by Fred Wenzel [:wenzel]
Modified: 2015-03-12 08:17 PDT (History)
10 users (show)
mzeier: needs‑downtime+
See Also:
QA Whiteboard:
Iteration: ---
Points: ---


Description Fred Wenzel [:wenzel] 2010-03-05 10:24:13 PST
Now that the tests are done and Build has signed off on the initial API, it's time to push Tuxedo into production.

I'll write some more info on Monday, but this is a bug for it, as a heads-up.
Comment 1 Shyam Mani [:fox2mike] 2010-03-08 07:33:47 PST
Nice, we can push this in when we have the required info :) Since this is internal, I guess we don't have to wait for a downtime window or anything.
Comment 2 Shyam Mani [:fox2mike] 2010-03-08 07:34:36 PST
Unless of course, bouncer the UI directly affects how our mirrors work, in which case this needs to be planned and probably announced.
Comment 3 Fred Wenzel [:wenzel] 2010-03-08 07:55:12 PST
(In reply to comment #2)
> Unless of course, bouncer the UI directly affects how our mirrors work, in
> which case this needs to be planned and probably announced.

Yea, we'll need downtime. At the very least, there were some schema changes, so we'll need to off-line while those are running. Due to these changes, the php bounce script will also have to be replaced.
Comment 4 Fred Wenzel [:wenzel] 2010-03-08 10:36:59 PST
Okay the basic steps are:

- Install a production instance of Tuxedo, just like the staging instance, including a `git submodule update --init`. (cf. bug 543452).
- Note that once the database update scripts have been run, neither the bounce script nor sentry will run anymore because of column name changes, so replace the bounce script with the bouncer/php directory (the easiest is probably to just move the existing directory out of the way and symlink the new php dir into its place, and putting a copy of the existing config file into .../cfg).
- Likewise for sentry.
- Replace the sentry cron job with a cron job running sentry-multi instead.
Comment 5 Fred Wenzel [:wenzel] 2010-03-08 11:09:13 PST
CCing Tim, who'll run this together with Dave on the IT side.
Comment 6 Jeremy Orem [:oremj] 2010-03-16 10:09:37 PDT
I don't really like the idea of being github's mercy to grab the code, especially the php code. Can we move that back in to svn, at least for now?
Comment 7 Fred Wenzel [:wenzel] 2010-03-16 10:54:48 PDT
(In reply to comment #6)
> Can we move that back in to svn, at least for now?

Yes, I can make it a branch of the Bouncer repository, if that makes it easier to deploy.

In the medium run, we should have git reference repositories in-house though, so we can stop doing the SVN/git dance, and instead just push to/pull from that repo for production, while development can stay on github or wherever else the respective dev likes.
Comment 8 Jeremy Orem [:oremj] 2010-03-16 12:01:42 PDT
A branch in svn will make it much easier to deploy. An in-house git repo is planned, but still needs to be set up.
Comment 9 Fred Wenzel [:wenzel] 2010-03-17 02:06:35 PDT
It won't be fun keeping this in sync, but for now this should do:
Comment 10 Jeremy Orem [:oremj] 2010-03-17 10:02:01 PDT
Do we need to keep it in sync? Can we just develop off svn and then move it to git in Q2?
Comment 11 Fred Wenzel [:wenzel] 2010-03-17 10:08:43 PDT
Yea, we'll be fine. I don't expect too many pushes between this release and the time when we move to git.
Comment 12 Fred Wenzel [:wenzel] 2010-03-24 03:26:47 PDT
Are we good to go here for next week? When would you like to deploy? Tuesday or Thursday maybe? Do you need any more information, or is there anything I can help with?

Comment 13 John O'Duinn [:joduinn] (please use "needinfo?" flag) 2010-03-24 08:20:35 PDT
(In reply to comment #12)
> Are we good to go here for next week? When would you like to deploy? Tuesday or
> Thursday maybe? Do you need any more information, or is there anything I can
> help with?

Whenever you settle on a day for this rollout, please check with RelEng that there is no releases going on that same day.
Comment 14 timellis 2010-03-24 14:21:46 PDT
I'm still not sure what will need to happen on the databases. I think I'll be pointing at some HTTP UI where I'll configure a database, and the UI will install its own schemas?
Comment 15 Fred Wenzel [:wenzel] 2010-03-25 00:24:49 PDT
It'll probably be the easiest if you collaborate with oremj on this, because he has done it before for the staging instance, but the basic idea is the following:

- Copy the database so we don't break the existing one
- (check out the source, make a virtualenv, install the requirements, point the settings to the copied DB, see )
- run sql/bouncer-add-lang.sql on it
- run sql/incremental.sql on it
- then on the command line (in the tuxedo dir, with the tuxedo virtualenv activated):
-- ./ syncdb
-- ./ migrate mirror 0001 --fake
-- ./ migrate

(I know those are a lot of steps, but it's because the production DB is so many iterations behind the dev DB. On the upside, these are the steps Jeremy already ran to set up staging, and they've proven to work fine.)

- finally: 
-- set up Apache to run the Django app
-- use the bounce script out of tuxedo's /bouncer/php/ dir, instead of the currently deployed one.
-- use the version of sentry (probably sentry-multi instead of its single-threaded friend) in the /sentry dir, instead of the currently deployed one.
Comment 16 Dave Miller [:justdave] ( 2010-03-25 00:35:50 PDT
And what makes this fun is that Jeremy set up staging on the same staging box that already had AMO Zamboni on it, which has the same prereqs.  The production sentry server is going to need all of the prereqs installed from scratch, which is where I got stuck the first time because we didn't have packages set up for all of them.  We probably do, now, since Zamboni has actually gone to production since then.
Comment 17 Jeremy Orem [:oremj] 2010-03-26 00:42:44 PDT
I can help you set up the virtualenv and pip. The main requirements are mod_wsgi and python2.6. After that pip will install whatever else the app needs.
Comment 18 Fred Wenzel [:wenzel] 2010-03-31 00:53:12 PDT
I completed the list of locales that we should deploy with, and made sure it the migration process still works. 

Are we ready to roll here for tomorrow?
Comment 19 matthew zeier [:mrz] 2010-04-01 09:08:39 PDT
Pushing off because of other internal activities.
Comment 20 matthew zeier [:mrz] 2010-04-07 00:23:56 PDT
Current status is rolled back right?

What steps were missed that made us pull back?  How to fix so when we retry this it works?
Comment 21 Fred Wenzel [:wenzel] 2010-04-07 02:06:23 PDT
Good questions, thanks. I was in the process of writing a postmortem wiki page about it and will share it soon.
Comment 22 Fred Wenzel [:wenzel] 2010-04-07 09:22:48 PDT
Here's the page:
Comment 23 matthew zeier [:mrz] 2010-04-27 19:15:59 PDT
Still on for Wednesday?  Start time?  Duration?
Comment 24 Fred Wenzel [:wenzel] 2010-04-27 20:30:24 PDT
Yes, definitely. Last time we launched at 9, that would wfm (or earlier, of course). Duration: I expect about 1h, though actual service downtime will be much shorter.
Comment 25 Fred Wenzel [:wenzel] 2010-04-28 08:51:56 PDT
We'll do it at 5pm instead.
Comment 26 Jeremy Orem [:oremj] 2010-04-28 18:58:40 PDT
Upgrade is complete.
Comment 27 Fred Wenzel [:wenzel] 2010-04-28 22:16:40 PDT
I meant to post that here:

"Good job, guys!"

Note You need to log in before you can comment on or make changes to this bug.