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
`./dist/tutor --version` raises an error:
Traceback (most recent call last):
File "main", line 4, in <module>
File "tutor/cli.py", line 21, in main
File "click/core.py", line 764, in __call__
File "click/core.py", line 716, in main
File "click/core.py", line 641, in make_context
File "click/core.py", line 1089, in parse_args
File "click/core.py", line 940, in parse_args
File "click/core.py", line 1477, in handle_parse_result
File "click/core.py", line 96, in invoke_param_callback
File "click/decorators.py", line 270, in callback
RuntimeError: Could not determine version
[1659] Failed to execute script main
To address this, we pass the version value directly to click.
This is for issue #156.
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.
After mysql has already been initialized, the data/mysql/mysql folder
exists and it is no longer necessary to re-initialize it. In fact, if
this folder exists, we mus tnot wait for the "MySQL init process done"
message, which never comes up.
See
c0454b9e0e/5.6/docker-entrypoint.sh
Close #136.
There may be a race condition, where the mysql container is initialized
without creating the root user. To address this, we wait until the right
message from the mysql logs. In practice, we should do even better by
running the provision.sh scripts directly inside the mysql container.
This is for issues #132 and #133
When booting for the first time, mysql has not properly initialized its
data. Here, we boot and stop mysql to make sure the root user has been
properly created.
Because we use "exec" and not "run" like in the local install, we need
to explicitely define the django settings (which sucks). This should be
improved by using k8s Jobs.
We re-introduce the dependency of the nginx container on the lms/cms
images. This dependency was removed to address a debugging scenario
which is actually not practical. Without this dependency, we are forced
to use an external docker-specific resolver which makes the local nginx
configuration incompatible with the kubernetes configuration.
