Hawthorn

Owned by Ned Batchelder (Deactivated)
Last updated: Aug 03, 2018
4 min read

This is not a list of the features and changes that will be available in Hawthorn.  This page is only for release concerns.  See the product announcements for changes that have been made since Ginkgo.


Put stuff here that we have to remember when we start packaging up for Hawthorn.  Please include your name when you add an item, so that we can get back to you with questions.

Stuff that must land before Hawthorn

Stuff you'd like to complete before Hawthorn

Migrating from Ginkgo to Hawthorn

The upgrade to Django 1.11 will requires a non-backward-compatible ALTER TABLE on the auth_user table, and so some outage will be required when upgrading from Ginkgo to Hawthorn.

Testing on a recent edx.master (prior to the Django 1.11 upgrade) also noted these MySQL database exceptions for a few essential operations.

  • Exception thrown during LMS/Studio login/registration and course enrollment:
    OperationalError: (1054, "Unknown column 'email_marketing_emailmarketingconfiguration.sailthru_activation_template' in 'field list'")
  • Exception thrown during during Studio course creation:
    ProgrammingError: (1146, "Table 'hawthornupgrade_sandbox_opencraft_hosting_edxapp.student_historicalcourseenrollment' doesn't exist")
Ned Batchelder (Deactivated)
February 2, 2018

Help me with the migration-algebra at work here: if we remove the migration from the Hawthorn branch, won't we have the same problem in Ironwood?

Jill Vogel
February 15, 2018

@Ned Batchelder (Deactivated) Anyone migrating directly from Ginkgo to Ironwood would have this problem, true.  I'm just covering the use case of migrating from Ginkgo to Hawthorn, then Hawthorn to Ironwood.

This approach essentially marks the field as "deprecated" for the Hawthorn release, so it can then be removed when Ironwood is cut from master.

Does that make sense?

Tomasz Gargas
February 27, 2018

@Ned Batchelder (Deactivated) a friendly ping  Do you think we could submit a PR that "deprecates" the field for the Hawthorn release?

Ned Batchelder (Deactivated)
February 27, 2018

Because the 0009 migration is the last one in that series, we can remove it from the hawthorn.master branch once it is created.  



Tomasz Gargas
February 28, 2018

Thanks for response, @Ned Batchelder (Deactivated)! Just to make sure I understand correctly, this 0009 migration won't be part of open-release/hawthorn.master?

Ned Batchelder (Deactivated)
February 28, 2018

@Tomasz Gargas yes, we could omit the migration from open-release/hawthorn.master, though given that Hawthorn will have a blocking change to the user table, we should be sure it really will help with deployments before we step outside the normal process for something like this.

Jill Vogel
March 11, 2018

FYI, @Sven Marnach did something similar for Ficus: https://github.com/edx/edx-platform/pull/14474

Sven Marnach
March 11, 2018

@Jill Vogel In the case of Ficus, we could actually achieve a zero-downtime migration.  For Hawthorn, this will likely be impossible due to the Django 1.11 upgrade, which as Ned mentions introduces an incompatible ALTER TABLE for the user table, so chances are we can't leave the old Ginkgo servers running while performing the Hawthorn migraions anyway.

Jill Vogel
March 12, 2018

Ah cool, thanks for the clarification, @Sven Marnach.  Will update the comments around migration, and let this thread go.

CC @Tomasz Gargas