- [Bugfix] Fix "Unable to resolve dependency" error during forum
initialisation
- [Feature] Add `settheme` command to easily assign a theme to a domain
name
- [Improvement] Modify nginx access logs to include request scheme and
server name (plugin developers should use the "tutor" log format)
- [Bugfix] Fix DNS resolution of restarted service
- [Feature] Restart multiple services with `local restart`
- [Feature] Make it possible to easily reload openedx gunicorn process
with `tutor local exec lms reload-gunicorn``
- [Improvement] Rename lms/cms_worker to lms/cms-worker in local
deployment
- [Improvement] Add the management plugin to the rabbitmq container
- [Improvement] Make it possible to run an Elasticsearch service on
https
When running "bundle exec rake search:initialize" in the forum, we were
getting the following error:
/openedx/ruby/lib/ruby/site_ruby/2.4.0/rubygems/resolver.rb:235:in `search_for': Unable to resolve dependency: user requested 'did_you_mean (= 1.1.0)' (Gem::UnsatisfiableDependencyError)
It happens this error suddently happened because rubygems-update was not
pinned to a specific version. v3.0.4 was working and v3.1.2 was not.
As it happens, we don't need rubygems-update, so we simply get rid of it
entirely.
To do so, we had to create a new log_format.
Plugin developers are strongly encouraged to start using this log format
by adding the `access_log /var/log/nginx/access.log tutor;` directive to
their extra nginx configurations.
In order to load this log format early, the `tutor.conf` config file had
to be renamed to something early in the alphabet... (hence starting by
an underscore) Older users would face an error on nginx reload, so older
"tutor.conf" files are automatically removed on config save.
Previously, a common error when restarting e.g: the lms or the cms was
that nginx redirected to the wrong container. For instance:
access studio.localhost
tutor local restart lms cms
access studio.localhost
In the second call to studio.localhost, we were frequently trying to
access the LMS, which resulted in a 400 error.
We solve this issue by setting a TTL of 10s on the nginx proxy name
resolution.
More docs:
http://nginx.org/en/docs/http/ngx_http_core_module.html#resolver
The management plugin exposes an http API that makes it possible to
monitor rabbitmq. By default, we do not expose the management dashboard.
As a consequence, the API is only usable by other internal containers.
- [Improvement] Switch edx-platform from open-release/ironwood.2 tag to
the open-release/ironwood.master branch
- [Security] Upgrade django to 1.11.28
- [Improvement] Make it possible to configure the elasticsearch heap
size
- [Bugfix] Fix broken elasticsearch environment variables
- [Improvement] Restore more recent Android app version (#289).
There are too many patches on top of ironwood.2, and it's not practical
to pull them all one by one. We still want to build on top of a specific
version, and not a branch, so we use a dirty hack to guarantee that the
docker image is properly rebuilt by CI when we change it.
Because we are running a version of elasticsearch older than Methusalem,
the docker environment variables were not properly taken into account.
For instance, the cluster name and "mlockall" settings were incorrect,
as we could see by running:
$ tutor local run lms curl elasticsearch:9200 | grep cluster_name
...
"cluster_name" : "elasticsearch",
$ tutor local run lms curl elasticsearch:9200/_nodes/process?pretty | grep mlock
...
"mlockall" : false
See
https://discuss.overhang.io/t/elastic-container-is-not-being-removed/312/3
for discussion.
This fix also introduces a new tutor configuration setting to adjust the
elasticsearch heap size.
A prior change used the ironwood.1 tag to build the Android app in an
attempt to solve #289. Turns out that this change was unnecessary. So
here we revert to a more recent release of the Android app. Instead of
building from the master branch (which might create suprises) we build
from a fixed release tag.
The source repo and version are customisable via build arguments.
This is for supporting json-based plugins. The great thing about this
change is that it allows us to easily print plugin version numbers in
`plugins list`.
- [Bugfix] Fix oauth authentication in dev mode
- [Improvement] Upgrade to the 3.7 docker-compose syntax
- [Improvement] The `dev runserver` command can now be run for just any
service
- 💥[Feature] `dev run/exec` commands now support generic options which
are passed to docker-compose. Consequently, defining the
`TUTOR_EDX_PLATFORM_PATH` environment variable no longer works. Instead,
users are encouraged to explicitely pass the `-v` option, define a
command alias or create a `docker-compose.override.yml` file.
By de-duplicating the code between dev.py and local.py, we are able to
support more docker-compose run/up/stop options passed from tutor. To do
so, we had to disable some features, such as automatically mounting the
edx-platform repo when the TUTOR_EDX_PLATFORM_PATH environment variable
was defined.
- [Improvement] Make it possible to override the project name in development mode
- [Bugfix] Fix user switching in development mode
- [Bugfix] Fix "k8s quickstart" crash
"Course visibility In Catalog" advanced CMS setting was being ignored
because the default the COURSE_CATALOG_VISIBILITY_PERMISSION and
COURSE_ABOUT_VISIBILITY_PERMISSION settings were incorrectly set to the
legacy default, which "see_exists".
See
https://discuss.overhang.io/t/catalog-visibility-in-tutor-deployed-open-edx/214
It makes more sense to document this command instead of adding it to the
`local` commands. If need be, in the future we should be able to re-add
it as a plugin.
This command adds a burden on the `local` and `k8s` command. It does not
make sense to provide this command out of the box, and not other
administration commands. Instead, we should better document how to run
regular `manage.py` commands from tutor.
Close #269.
- [Improvement] Add `k8s-deployments-nginx-volume-mounts` patch
- [Bugfix] Fix running forum locally when both elasticsearch and mongodb
are not activated (#266)
- [Bugfix] Fix MongoDb url in forum when running separate service (#267)
- 💥[Improvement] Better `dev` commands, with dedicated development
docker image. One of the consequences is that the `dev watchthemes`
command is replaced by `dev run lms watchthemes`.
- [Improvement] `images` commands now accept multiple `image` arguments
MONGOHQ_URL was not properly set when MONGODB_HOST/PORT was customised.
That's because the environment variable was being defined in the
Dockerfile, and not at runtime.
Close #267
The `dev` commands now rely on a different openedx-dev docker image.
This gives us multiple improvements:
- no more chown in base image
- faster chown in development
- mounted requirements volume in development
- fix static assets issues
- bundled ipdb/vim/... packages, which are convenient for development
Close #235
- [Feature] Introduce tutor docker image
- [Feature] Introduce `local hook` command for plugin development.
- [Bugfix] Persist `private.txt` file between two runs of `config save`.
(#247)
- [Improvement] Added configuration values to limit the number of
gunicorn workers for the LMS and CMS.
- 💥[Improvement] Get rid of mysql-client container
- [Improvement] Add "local-docker-compose-lms/cms-dependencies" plugin
patches
- [Improvement] Use "exec" instead of "run" to initialise local platform
This has an impact on plugin hooks. Plugin hooks that needed to run
inside mysql-client now need to run inside mysql container. This
simplifies the deployment, as we no longer have an empty mysql-client
container sitting around.
When mysql is not enabled (ACTIVATE_MYSQL=False) the mysql container is
simply a mysql client.
We ran into an issue when trying to run migrations when the MinIO plugin
is activated. As seen in issues #243 and #244, the
certificates.0003_data__default_modes migration requires access to
MinIO. To do so, the MinIO host must be reached. That means that SSL
certificates must be in place (if https is enabled) and that the nginx
server must be booted. However, it does not make sense to require that
the minio container depends on the nginx container. So, in effect, we
need a fully working platform to run migrations.
In a sense, this is better as it harmonises the init task with k8s: in
k8s, init was already run with exec.
Next step is to get rid of these ugly mysql-client/minio-client
containers that must be up at all times. It would be much simpler to
just exec the commands inside the mysql/minio containers.
All existing plugins are added to the binary bundle, in their latest
version, so that users don't need to pip install tutor.
Also, the tutor MANIFEST.in file was removed to simplify the management
of package data.
Close #242.
- [Feature] Modify ``createuser`` commands to define a password from the
command line
- [Improvement] Better yaml value parsing from command line
- [Feature] Add `dev exec` command
- [Bugfix] Fix incorrect notes settings definition
- [Improvement] Make it possible to start/stop/reboot a selection of
services
- [Improvement] Add `local/k8s reboot` commands
- [Improvement] Add `-U/--unset` option to `config save`
- [Bugfix] Fix insecure static asset loading when web proxy is enabled
- [Improvement] Rename `SECRET_KEY` configuration parameter to
`OPENEDX_SECRET_KEY`
- [Improvement] Add support for SSL and TLS in external SMTP server
(#231)
- [Bugfix] Fix missing video transcripts in LMS (#229)
- [Improvement] Make it possible to enable/disable multiple plugins at
once
- [Improvement] Add a few local and k8s patches for plugins
Video transcripts uploaded in the CMS were not visible in the LMS. This
was a symptom caused by the fact that the LMS and the CMS do not share
the same MEDIA_ROOT. We initially thought that data uploaded in the CMS
(such as transcripts) was stored in a shared data service, such as
mongodb. It is, in fact, not. This makes it even more important to run
an object storage service like minio for distributed services.
Close #229
The 0003 migration from the certificates app of the LMS requires that
the S3-like platform is correctly setup during initialisation. To solve
this issue, we introduce a pre-init hook that is run prior to the LMS
migrations.
- [Feature] Creation of a plugin system
- [Feature] Kubernetes support out of beta
- [Improvement] Switch to pinned image tags for easier upgrades
- 💥[Improvement] Remove the `-y/--yes` option: `tutor config save` is
now non-interactive by default. Use `-i/--interactive` to force
interactive mode.
- 💥[Improvement] Replace the `databases` command by `init`.
- [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 initialisation
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.
