Xqueue containers consist of two services: a gunicorn service, that
receives requests from LMS/CMS, and a worker service. I guess the worker
service receives orders from the gunicorn service, through rabbitmq.
(but I'm less than certain about that).
While adding xqueue containers, we refactored the way mysql databases
are created, and how the root password is loaded. Also, we silenced some
options from the configure script.
Images are no longer built locally, Instead, they are downloaded from
docker hub. This completely changes config file organisation. In
particular, we no longer copy configuration files to the original docker
image.
XModule could not be found because the compiled package could not be
found in edx-platform/common/lib/xmodule. This was due to the fact that
build operations realised after a VOLUME statement are ignored if they
affect the content of this volume (although it's not mounted during
build, of course). This is not a bug, it's a feature of the VOLUME
statement :)
Demo course about pages were not available (and probably many other
pages as well) because the preview url was the same as the real url.
Kudos to @dannielarriola for solving this!
Close issues #11#7.
By using variables in the nginx configuration to point to lms/cms, we
allow nginx not to require that lms and cms are up to run. This is
convenient for debugging production settings: just launch an nginx, then
runserver in an lms.
This allows the user to run their own devstack inside the containers.
Yay!
Also, we handle file permissions cleanly: in docker-entrypoint.sh we
chmod the data and edx-platform files to the same UID of the user on the
host machine. No more permission headaches!
When running "wait-for-mysql.sh", the "echo 'show tables' | manage.py
dbshell" command is always considered a success, even if the database is
unreachable ($? == 0). So we replace this command by a global system
check.
This closes #3.
