tl;dr: Some db tables are being weird. You’ll need to run a management command before applying migrations that just landed in master. For devstack users, the command is:
./manage.py lms --settings=devstack drop_djcelery_tables Hi all, I recently did some work on edx-celeryutils, allowing us to make use of the celery chord primitive to speed up future grade report execution times. As part of this work, I have had to upgrade the django-celery requirement from 3.1.16 to 3.2.1. The problem this raises is that the project moved from South to Django migrations over this version, and a simple --fake-initial won’t resolve the problem due to the old and new tables being slightly different. However, we currently use the old tables in exactly zero locations. The fix is to run my new management command, drop_djcelery_tables. This command will drop the relevant database tables (iff they are empty), allowing you to grab the newly-merged-into-master celeryutils migrations and run them. If you haven’t run the management command yet but have tried to run migrations, you’ll get a “table already exists” error. The fix here is easy - just go run the management command and try to run your migrations again. Sandboxes and devstack images have already been updated, so newly provisioned machines should not require any special handling. Please let me know if you have any further questions. Thanks! edx-celeryutils work: https://github.com/edx/edx-celeryutils/pull/5 Celery chords info: http://docs.celeryproject.org/en/3.1/ userguide/canvas.html#chords -- Eric Fischer -- You received this message because you are subscribed to the Google Groups "General Open edX discussion" group. To view this discussion on the web visit https://groups.google.com/d/msgid/edx-code/CALRwqNbvCD3a9JTmW9sAkvAHSg_v4g3cnbH%3Dbw8hYxiH-BzOEQ%40mail.gmail.com.
