Apply django migrations

[diox]

We currently only use schematic and don't apply django migrations at all at deploy time. This is causing issues like https://github.com/mozilla/addons/issues/5962 because we do depend on some django models.

The current list of unapplied django migrations on dev is:

admin
 [ ] 0001_initial
 [ ] 0002_logentry_remove_auto_add
auth
 [ ] 0001_initial
 [ ] 0002_alter_permission_name_max_length
 [ ] 0003_alter_user_email_max_length
 [ ] 0004_alter_user_username_opts
 [ ] 0005_alter_user_last_login_null
 [ ] 0006_require_contenttypes_0002
 [ ] 0007_alter_validators_add_error_messages
 [ ] 0008_alter_user_username_max_length
contenttypes
 [ ] 0001_initial
 [ ] 0002_remove_content_type_name
product_details
 [ ] 0001_initial
 [ ] 0002_auto_20151006_1348
sessions
 [ ] 0001_initial
waffle
 [ ] 0001_initial
 [ ] 0002_auto_20161201_0958
 [ ] 0003_update_strings_for_i18n

We need to review them and apply them (or fake some we might not want, but would need to be very careful about doing that as it will introduce inconsistencies).

FWIW the one blocking mozilla/addons#5962 is 0002_remove_content_type_name.

[diox]

Note that it's different from https://github.com/mozilla/addons/issues/3600 which is about doing the complete switch to django migrations. We just need the existing migrations from django applied at the moment, nothing more.

[diox]

• admin:
  • Seems safe. It does not alter the database
• auth
  • Needs some investigation, not sure how it interacts with our custom user model. Edit: as it turns out, we already had the column changes these migrations bring.
• contenttypes
  • Safe, we definitely want that one applied
• product_details
  • Only a data migration that I don't think we care about. Could be applied, we don't care about product_details' database backend.
• sessions
  • Only the initial migration. We don't care about the sessions database backend anyway.
• waffle
  • At first glance both migrations look fine and don't alter the database

So it looks safe overall, just need to check the auth ones.

[diox]

Note: locally, anyone that built their container fairly recently has all those migrations marked as applied, since the database was built from a syncdb. It's only dev/stage/prod that are problematic.

[diox]

I did some testing and ended up running:

• dev ./manage.py migrate --fake-initial
• stage ./manage.py --fake-initial contenttypes

Both completed successfully.

As we're not using django migrations yet (that's https://github.com/mozilla/addons/issues/3600) I don't want to start requiring it in deploy yet, so my plan is to check that everything is ok on dev, then run the migrate --fake-initial once on stage & prod as well, and stop there for now.

[AlexandraMoga]

@diox should I look at something specific for this?

[diox]

@AlexandraMoga I was waiting for https://github.com/mozilla/addons/issues/5962 to be verified. There is nothing specific to check, just keep an eye out for anything out of the ordinary. I'll mark this one as qa not needed.

[diox]

Also ran the migrations on stage, and left a note in the release docs to do it on prod.