Remove 'runserver' in favor of 'start'

[kdmccormick]

Context

There are two ways to bring up services in dev mode:

1. tutor dev runserver myservice
2. tutor dev start [myservice1 myservice2 ...]

Command 1 has the advantage of accepting volume mounts and allowing debugger attachment.

Command 2 has the advantage of:

• accepting multiple services, or
• accepting no services, in which case all enabled services are started. This is helpful in that it doesn't "leave out" any important services, such as the MFE container. Relevant forum thread.

Are there other substantive differences? Could they be reconciled into a single command that supports all features?

Update

We have already:

• added the ability for tutor [dev|local] start to mount volumes using the new --mount command
• allowed debugger attachment for containers started by tutor dev start
• marked tutor dev runserver as deprecated, since it no longer has any advantages over tutor dev start. This was done in: Deprecate 'runserver' in favor of 'start' #61

Acceptance Criteria

• In order to give folks time to stop using runserver, wait until Tutor v14 is released.
• Go through official plugins. For each plugin:
  • Ensure that the plugin is ported to the V1 API
  • Ensure that the plugin hooks into the COMPOSE_MOUNTS filter in order to automatically bind-mount folders as appropriate.
  • Replace any references to runserver with start
  • Replace any references to the --volume option with an equivalent usage of the --mount option.
• Remove the implementation of tutor dev runserver.

[regisb]

Are there other substantive differences?

• runserver allocates a tty, which makes it possible to breakpoint() python code.
• containers run as runserver are no longer reachable by containers run as start -- and this is a problem. For instance, with tutor dev runserver lms and tutor dev start -d cms then we can no longer login to the Studio, because the CMS makes an internal call to the LMS.

We can certainly do a better job at better documenting these commands, but I'm afraid that we need both.

[kdmccormick]

@regisb Is there any reason we wouldn't want start to allocate a tty like devstack's dev.up does?

[regisb]

This is a very good point! I attempted this some time ago and it didn't work, though I can't remember why. I tried again just now and I now realise that I can docker attach to any container that was started with tty/stdin_open: true, thus allowing me to troubleshoot any container without the use of docker-compose run.
Thus, yes we can get rid of docker-compose run for long-running services, such as runserver. This is fantastic news, as it allows us to greatly simplify the CLI 🥳

EDIT: I just remembered that docker-compose run also allows bind-mounting volumes from the host. We would have to simplify the bind-mounting of folders and repositories (see #43) before we can really get rid of docker-compose run. (ping @kdmccormick)

[kdmccormick]

@regisb Awesome!

I'm excited that we can drop tutor dev runserver. Would you still want tutor dev run <service> <cmd> to exist for running one-off commands? For example: tests, migrations, management commands, and so on.

Or should those workflows be replaced with tutor dev start <service> && tutor dev exec <service> <cmd>?

[regisb]

Would you still want tutor dev run to exist for running one-off commands? For example: tests, migrations, management commands, and so on.

Yes, dev run commands would still be useful. For instance I use the following commands very frequently:

• tutor dev run lms bash
• tutor dev run --no-deps lms ./manage.py lms shell
• tutor local run ecommerce ./manage.py shell -c "from django.contrib.auth import get_user_model; get_user_model().objects.filter(email='[email protected]').update(is_staff=True, is_superuser=True)"

For one-off tasks, exec is still inferior to run because it ignores the environment variables defined in the docker-compose*.yml files.

[kdmccormick]

Yes, dev run commands would still be useful.

I agree. Since switching from devstack, I do appreciate how Tutor can run commands with spinning up a persistent container.

exec is still inferior to run because it ignores the environment variables defined in the docker-compose*.yml files.

I have not been able to recreate this. I tried adding an environment variable to docker-compose.yml:

$ vi $(tutor config printroot)/env/local/docker-compose.yml
    ...
    lms:
      image: docker.io/overhangio/openedx:13.1.5-nightly
      environment:
        SERVICE_VARIANT: lms
        UWSGI_WORKERS: 2
        SETTINGS: ${TUTOR_EDX_PLATFORM_SETTINGS:-tutor.production}
        MY_VAR: my_val  # <- added this line
    ...
$ tutor dev run lms printenv MY_VAR
my_val
$ tutor dev start -d lms
$ tutor exec lms bash
app@f4960a487696:~/edx-platform$ echo $MY_VAR
my_val
app@f4960a487696:~/edx-platform$

and found that both exec and run pick up on the new environment variable.

I'll update the acceptance criteria of this issue to keep run in the CLI because I think it's useful, but I'm still curious to understand what's going on with environment variables.

[regisb]

and found that both exec and run pick up on the new environment variable.

Right. I guess I was wrong about that. Now that you mention it, the actual problem that I faced in the past is that exec bypasses the Docker entrypoint. Sorry about the confusion. Tutor used to run images with heavy entrypoint scripts. This is mostly no longer the case, but it might still cause surprises from time to time.

[kdmccormick]

the actual problem that I faced in the past is that exec bypasses the Docker entrypoint.

Whew, that is a very confusing Docker nuance 😛

That sheds light on one weird behavior I've noticed: using tutor [local|k8s] exec, Django management commands almost work perfectly, except that DJANGO_SETTINGS_MODULE isn't set. After I run export DJANGO_SETTINGS_MODULE=[lms|cms].envs.tutor.production, everything works fine.

I think that it's because the Dockerfile sets DJANGO_SETTINGS_MODULE via an entrypoint script instead of setting it directly as using ENV. It seems like DJANGO_SETTINGS_MODULE is the only environment variable set this way.

Do you know of any reason we couldn't pull DJANGO_SETTINGS_MODULE into the Dockerfile?

[kdmccormick]

Work-in-progress PR: kdmccormick/tutor#7

This is effectively blocked by #43 , because we can't remove runserver until we have a replacement strategy for mounting local code, so I'm putting down that PR for the time being.

[kdmccormick]

@regisb I updated the acceptance criteria of this ticket, can you take a look to see if you agree?

[regisb]

I updated the acceptance criteria of this ticket, can you take a look to see if you agree?

I do! Sorry about the delay :-/

[kdmccormick]

No worries, thanks!

@Carlos-Muniz If/when you need a new ticket, this one is ready to go.

[Carlos-Muniz]

@kdmccormick I'm going to tackle this ticket if you want to assign it to me.

[Carlos-Muniz]

Of the official Tutor Plugins:

• Changes were made:
  • tutor-ecommerce: docs: replace runserver with start overhangio/tutor-ecommerce#31
• Did not require any changes:
  • tutor-android
  • tutor-discovery
  • tutor-forum
  • tutor-mfe
  • tutor-minio
  • tutor-notes
  • tutor-webui
  • tutor-xqueue
• Source code is not available:
  • tutor-cairn
  • tutor-machine
  • tutor-monitor

[kdmccormick]

I think a few of these services should add callbacks to the COMPOSE_MOUNTS filter in order to enable local repo auto-mounting:

• tutor-xqueue: --mount xqueue should auto-mount to /openedx/xqueue in the xqueue and xqueue-job services.
• tutor-forum: --mount cs_comments_service should auto-mount to /app/cs_comments_service in the forum and forum-job services.
• tutor-notes: --mount edx-notes-api should auto-mount /app/edx-notes-api in the notes and notes-job services.

I agree about the rest of the services.

[Carlos-Muniz]

Local repo auto-mounting has been enabled for the following repos as requested:

• tutor-forum
• tutor-notes
• tutor-xqueue

[kdmccormick]

New removal PR, on top of nightly instead of master: overhangio/tutor#718