2.1. Open edX Ginkgo Release

This section describes how to install the Open edX Ginkgo release.

2.1.1. What’s Included in Ginkgo

The Open edX Ginkgo release contains several new features for learners, course teams, and developers. For more information, see Open edX Ginkgo Release.

2.1.2. What Is the Ginkgo Git Tag?

A git tag identifies the version of Open edX code that is the Ginkgo release. You can find the most up-to-date git tag for the current Open edX release on the Open edX Releases Wiki page.

The following Open edX git repositories have the Ginkgo git tag:

  • edx-platform
  • configuration
  • course_discovery
  • cs_comments_service
  • xqueue
  • ecommerce
  • ecommerce-worker
  • edx-analytics-configuration
  • edx-analytics-dashboard
  • edx-analytics-data-api
  • edx-analytics-pipeline
  • edx-certificates
  • edx-custom-a11y-rules
  • edx-demo-course
  • edx-documentation
  • edx-notes-api
  • edx-ui-toolkit
  • notifier
  • ux-pattern-library

2.1.3. Installing the Ginkgo Release

You can install the Open edX Ginkgo release using Devstack or Fullstack.

Review the prerequisites and instructions for each option, and then choose the option that best meets your needs. Ensure that you install the required software to run the Open edX platform.

Ginkgo releases have git tag names like open-release/ginkgo.1. The available names are detailed on the Open edX Releases Wiki page.

2.1.4. Upgrading from the Ficus Release

One approach to upgrading an existing installation of the Open edX Ficus release to the Ginkgo release is to make a fresh installation of the Ginkgo release on a new machine, and move your data and settings to it.

To move and upgrade your Ficus data onto a Ginkgo installation, follow these steps.

  1. Be sure that your Ficus installation is on Ficus.4. The Ficus.4 release provided required database migrations beyond what was in Ficus.3. The only version of Ficus that will upgrade to Ginkgo successfully is Ficus.4.

  2. Stop all services on the Ficus machine.

  3. Dump the data on the Ficus machine. Here’s an example script that will dump the MySQL and Mongo databases into a single .tgz file. The script will prompt for the MySQL and Mongo passwords as needed.

    MYSQL_CONN="-uroot -p"
    echo "Reading MySQL database names..."
    mysql ${MYSQL_CONN} -ANe "SELECT schema_name FROM information_schema.schemata WHERE schema_name NOT IN ('mysql','information_schema','performance_schema')" > /tmp/db.txt
    DBS="--databases $(cat /tmp/db.txt)"
    NOW="$(date +%Y%m%dT%H%M%S)"
    echo "Dumping MySQL structures..."
    mysqldump ${MYSQL_CONN} --add-drop-database --no-data ${DBS} > ${SQL_FILE}
    echo "Dumping MySQL data..."
    # If there is table data you don't need, add --ignore-table=tablename
    mysqldump ${MYSQL_CONN} --no-create-info ${DBS} >> ${SQL_FILE}
    for db in edxapp cs_comment_service_development; do
        echo "Dumping Mongo db ${db}..."
        mongodump -u admin -p -h localhost --authenticationDatabase admin -d ${db} --out mongo-dump-${NOW}
    tar -czf openedx-data-${NOW}.tgz ${SQL_FILE} mongo-dump-${NOW}
  4. Copy the .tgz data file to the Ginkgo machine.

  5. Stop all services on the Ginkgo machine.

  6. Restore the Ficus data into the Ginkgo machine. As an example, you might use the following commands.

    $ tar -xvf openedx-data-20170811T154750.tgz
    $ mysql -uroot -p < mysql-data-20170811T154750.sql
    $ mongorestore -u admin -p -h localhost --authenticationDatabase admin --drop -d edxapp mongo-dump-20170811T154750/edxapp
    $ mongorestore -u admin -p -h localhost --authenticationDatabase admin --drop -d cs_comment_service mongo-dump-20170811T154750/cs_comment_service_development
  7. To migrate data from Ficus to Ginkgo, you need to drop the database tables used by djcelery. These tables should be empty in your Ficus data, so it is safe to drop them. The edx-platform application has a management command to check that they are empty and drop them:

    $ sudo su - -s /bin/bash edxapp
    edxapp@xyz:~$ . edxapp_env
    edxapp@xyz:~$ cd edx-platform/
    edxapp@xyz:~/edx-platform$ python manage.py lms drop_djcelery_tables --settings=aws
  8. Run the Ginkgo migration script, which will update your Ficus data to be valid for Ginkgo:

    $ /edx/app/edx_ansible/edx_ansible/util/install/sandbox.sh --tags migrate
  9. Copy your configuration files from the Ficus machine to the Ginkgo machine.

  10. Restart all services. Upgrading Django Oscar

The Ginkgo release of Open edX upgrades Django Oscar to version 1.4. If you have an existing installation of Open edX with the E-Commerce service, and your orders table is larger than a million rows, there is an additional step to upgrade your Django Oscar installation.

The migration includes a change to the guest_email column in the orders table. This change is applied automatically. If your orders table is larger than a million rows, this migration may lock the table for an extended amount of time. The E-Commerce service does not normally use the guest_email column. If your installation does not use this column, you can avoid the table lock by using the --fake argument in migrating the orders table, running the migrate command in the following form.

./manage.py migrate orders 0013 --fake

2.1.5. Upgrading to a Subsequent Ginkgo Release

Occasionally, we release updates to Ginkgo. For example, the second release of Ginkgo will be open-release/ginkgo.2. The steps to upgrade differ based on your original installation method. Upgrading a Vagrant Installation

Devstack and Fullstack are installed using Vagrant. To upgrade from one Ginkgo release to another, run the following commands in the host operating system:

$ export OPENEDX_RELEASE=open-release/ginkgo.2
$ vagrant provision Upgrading a Native Installation

If you installed Open edX using the Open edX Native Installation, you can upgrade from one Ginkgo release to another by re-running those steps using your desired Ginkgo tag as the new value for OPENEDX_RELEASE.