This allows us to deploy much faster: all we have to do is to copy the
assets from the container to the shared volume.
We also changed the way themes are managed: similarly to static assets,
they are now packaged inside the docker image.
By default, open response assessment files are sent to S3. Here, we
store uploaded files with the "filesystem" backend instead. To do so, we
must install a forked version of ora2 that fixes a couple issues.
Note that the "django" backend is not very usable, as file extensions
are lost on upload.
Close #97
We don't need to run "chmod" on openedx files outside of development
mode. So, there is no need to set the USERID environment variable in
most cases. This should considerably accelerate pretty much all commands
that involve the openedx container.
For discussion consult PR #98.
webpack requires the NODE_ENV environment variable which is incorrectly
set "paver update_assets" in development mode. To avoid this issue, we
split update_assets into its subparts.
Theme assets generation relies on a cache stored in memcache. We were
observing incorrect urls generated for theme/xblock assets whenever
assets had been generated for another platform. For instance, when
viewing an XBlock in the LMS right after running "paver update_assets"
in the cms.
To solve this problem, we cache staticfiles assets in entries with
different prefix.
Close #95
Added the possibility to easily change the ports that nginx listens to.
This is useful, for instance when Apache or Nginx already runs on the
host. With this change, it is no longer necessary to edit the
docker-compose file to modify these ports.
To deploy with alternate ports, add a `.env` file with the following
contents:
```
OPENEDX_NGINX_PORT=8080
OPENEDX_NGINX_TLSPORT=8443
```
Rabbitmq was not configured to restart on failures. It does not explain
why rabbitmq crashes (with exit code 255, see issue #80), but this should be sufficient
as a quick fix.
When the ENABLE_EDXNOTES feature is added to the CMS, it is not
necessary to modify the advanced module list to activate notes for each
course.
Close #79.
The `update_assets` paver task of the lms/cms attempt to manually
uninstall some old packages. We should not concern ourselves by this,
since all requirements are installed from scratch in every docker image.
Close #73.
Duplicate "environment" statement in the docker-compose.yml was causing
the first one to be forgotten. Hence, the cms celery worker was running
with LMS settings.
Close #72
