1005212 - Update/migrate Affiliates-stage to Affiliates 2.0

Status: RESOLVED FIXED

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

Description

[Osmose [:osmose, :mkelly]]

Here's how it's going to go down, kids. There's a few manual steps to perform for updating/migrating stage to the latest and greatest Affiliates code:

1. Create a copy of the current stage database and set it up on the same database host as the current database is one (named something like affiliates-stage-copy or something).
2. Back-up the media directory in case it gets borked during the migration.
3. Pull and check out the latest code.
4. Create a new settings file in affiliates/settings/local.py based off the affiliates/settings/local.py-dist file. Copy over matching settings from the existing settings/local.py file and fill in new ones if necessary. Include the copy of the staging database as a new entry in the DATABASES setting, with a name like 'staging' or something.
5. Manually delete any tables from the database that start with the prefix 'badges_', 'news_', or 'banners_'.
6. Run a fake migration to reset the banners table to the zero migration:

   ./manage.py migrate --fake --delete-ghost-migrations banners zero

7. Run the migrations:

   ./manage.py migrate --delete-ghost-migrations

8. Run the data migration command, passing in the name you gave to the staging database in the DATABASES setting:

   ./manage.py migrate_v1_banners staging

9. Run chief!

_Hopefully_ that should work. If not, well, that's why we have staging servers. Yay! Thanks!

Comment 1

[Chris Turra [:cturra]]

lets schedule this for monday :)

Comment 2

[Osmose [:osmose, :mkelly]]

Oh, as part of the settings you'll need a keyfile and some codes for the Google Analytics API. I am in the process of getting these generated for you.

Comment 3

[Osmose [:osmose, :mkelly]]

Settings and keyfile have been emailed.

Comment 4

[Osmose [:osmose, :mkelly]]

Oh, also forgot to note that we should set up a cron job to run bin/nightly_update.sh like we did for dev. I think for stage, since we want it to be prod-like, we should set it to run once every 24 hours, preferably near the end of the day UTC time (23:00 UTC would work fine).

Comment 5

[Chris Turra [:cturra]]

we've worked through these steps and modified them a bunch. stage appears to be functioning as expected now.

Comment 6

[Osmose [:osmose, :mkelly]]

I'll post update steps shortly, but one thing I realized we didn't do was make the entire media directory into a symlink to the netapp storage (and make sure the uploads folder still exists within it with the old images, although this time it'll be an actual folder on the storage instead of a symlink within media).

Comment 7

[Osmose [:osmose, :mkelly]]

Here's the updated steps based on what we found out yesterday:

1. Create copies of old tables with a prefix, like `old_`. The tables we need saved are: badges_category, badges_subcategory, badges_badge, banners_bannerimage, badges_badgeinstance, and banners_bannerinstance.

   create table old_badges_category like badges_category;
   insert into old_badges_category select * from badges_category;

2. Back-up the media directory and replace it with a symlink to shared netapp storage. Ensure the uploads folder is still within media and has the old images.
3. Run `git reset --hard` in the lib directory to reset the product_details files in git.
4. Run `git pull origin master` to pull the latest code, then `git submodule sync` and `git submodule update --init --recursive` to update the submodules.
5. Create a new settings file in affiliates/settings/local.py based off the affiliates/settings/local.py-dist file. Copy over matching settings from the existing settings/local.py file and fill in new ones if necessary.
   - Set STYLUS_BIN to /usr/bin/stylus
   - Copy the EMAIL_BACKEND and EMAIL_HOST settings.
   - Google settings and keyfile will be emailed.
6. Manually delete any tables from the database that start with the prefix 'badges_', 'news_', `djcelery`, `celery`, or 'banners_'.

   drop table badges_badge, badges_badgeinstance, badges_badgepreview, badges_category, badges_clickstats, badges_leaderboard, badges_subcategory;
   drop tables djcelery_crontabschedule, djcelery_intervalschedule, djcelery_periodictask, djcelery_periodictasks, djcelery_taskstate, djcelery_workerstate;
   drop tables celery_taskmeta, celery_tasksetmeta;
   drop tables banners_banner, banners_bannerimage, banners_bannerinstance;
   drop tables news_newsitem;

7. Run a fake migration to reset the banners table to the zero migration:

   ./manage.py migrate --fake --delete-ghost-migrations banners zero

8. Run the links app migrations:

   ./manage.py migrate links

9. Run the migrations:

   ./manage.py migrate

10. Run the data migration command, passing in the prefix you used for the old tables:

   ./manage.py migrate_v1_links old_

11. Run chief!
12. Read over existing cron jobs and remove unnecessary ones. Create a cron job to run ./bin/nightly_update.sh once a night at 23:00 UTC.

Comment 8

[Osmose [:osmose, :mkelly]]

Also, can you email me a copy of the pre-migration database backup you made? We need it to recover some test data that we want to check against to make sure the migration worked correctly.

Comment 9

[Osmose [:osmose, :mkelly]]

s/email/whatever form of data transfer works for you/

Comment 10

[Chris Turra [:cturra]]

i have updated the symlinks as requested and sent you the database dump from stage as requested.

Comment 11

[Osmose [:osmose, :mkelly]]

Another extra step I noticed we should do before running chief:

10.5. Run back one migration in the banners app and then run them forward to re-run the banner size migration:

    ./manage.py migrate banners 0004
    ./manage.py migrate banners

Comment 12

[Osmose [:osmose, :mkelly]]

Also step 13: Run ./bin/nightly_update.sh once to populate the leaderboard/locale info/etc.

Comment 13

[Osmose [:osmose, :mkelly]]

Oh yeah, it's been a week, we can probably call this resolved. :D