Having an identical "ironwood" tag for all releases is not practical, in
particular for breaking changes. Thus, docker images are now pinned to
the tutor version that they were build with.
Thus, we remove the -y/--yes options, which were kind of unintuitive,
and we add instead `-i/--interactive`. The quickstart commands remain
interactive by default, but can be silenced with `-I/--non-interactive`.
- [Improvement] Upgrade to ironwood.2
- [Improvement] Add `-y/--yes` option to `local quickstart` for non-interactive quickstart
- [Improvement] Persist LMS/CMS logs to disk by default (with collaboration from @silviot 💪)
- [Bugfix] Fix installing a locally cloned requirement repository
- [Improvement] Add `--no-cache` option to `images build`
- [Improvement] Make it possible to configure the notes service hostname
- [Improvement] Better, more robust MySQL initialization
For initializing the mysql database, we now run the mysql client from
the mysql container. That means that the mysql client is no longer
required in the openedx container, as previously suggested in PR #209.
When running `pip install -r /path/to/x.txt`, relative paths listed in
x.txt are supposed to be relative to the current folder, and not the
x.txt folder. This results in an error during `pip install`:
./xblock-poll/ should either be a path to a local project or a VCS
url beginning with svn+, git+, hg+, or bzr+
This error was first reported here:
https://discuss.overhang.io/t/installing-custom-xblock/61
Settings the number of workers for the LMS and the CMS to 2*|CPU|+1
results in 4*|CPU]+2 gunicorn workers, which is too much for a laptop to
cope with.
Close #207
Installing from pip was broken because, for some reason, the
templates/apps/xqueue/settings/ folder contained a __pycache__ folder
with compiled *.pyc files. Rendering the binary files was failing
miserably.
Login from localhost/studio.localhost was broken on Ironwood because the
session cookie was configured to be stored under the production domain
name. We fix this by setting the SESSION_COOKIE_DOMAIN to None: in the
edx-platform code, this corresponds to using the current request domain.
Now that the correct webpack settings are loaded by the `update_assets`
command in Ironwood, we can stop relying on the `openedx-assets` script.
Actually, we could probably remove it.
- [Feature] Multiple platforms on a single server \o/
- [Feature] Easily configure web proxy on the host
- [Bugfix] Fix `images pull all` command which failed on "all" image
- [Improvement] Add configurable mongodb, SMTP and rabbitmq
authentication
- [Improvement] Harmonize mysql username/password configuration
parameters
- [Feature] Configurable and pluggable data storage backends (#114)
It was tricky to define correct settings: the "localfs" default storage
backend was causing incorrect urls of the form "/media/<id>/<name>.csv".
Close #143
Configuration values can be loaded from the system environment by adding
a "TUTOR_" prefix.
Environment values supersede values from the user configuration file, so
that we can set values from the command line with "KEY=VAL tutor config
save --silent" even when KEY is already present in the user
configuration file.
Environment is no longer generated separately for each target, but only
once the configuration is saved.
Note that the environment is automatically updated during
re-configuration, based on a "version" file stored in the environment.
- [Improvement] Install python requirements in virtual env in docker
image
- [Bugfix] Add missing volume for theme development
- [Improvement] Rename "config [non]interactive" command to "config save
[--silent]"
- [Improvement] More explicit logging during environment generation
- [Improvement] Configurable docker images (#122)
- [Bugfix] Fix "android pullimage" command
- [Improvement] Do not upgrade images as part of quickstart
- [Bugfix] Fix USERID setup in development mode and various dev-related
docs (#177)
USERID environment variable was no longer passed to docker image in
development mode.
We take the opportunity to improve the documentation regarding the dev
environment.
Close #177.
- [Minor] Minimum required `click` version is 7.0 (#171)
- [Bugfix] Fix `runserver` dev command (#172)
- [Minor] Fix non-https link to documentation in pypi
- [Minor] Fix `createuser` documentation
Mysql triggers "Host 'xxx' is not allowed to connect to this MySQL
server" error because of race condition.
This was an issue that had been (painfully) solved in v2 and has reared
its ugly head again in v3.
Close #159
Close #160
Replace all make commands by a single "tutor" binary. Environment and
data are all moved to ~/.tutor/local/share/tutor. We take the
opportunity to add a web UI and revamp the documentation.
This is a complete rewrite.
Close #121.
Close #147.
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.
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.
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
Template files are now directly loaded in the configurator container, so
that it is possible to run the configurator container directly, outside
of this project.
