-
Notifications
You must be signed in to change notification settings - Fork 446
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feat!: don't run Celery workers in dev mode #1041
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,2 @@ | ||
- 💥[Feature] Use Docker compose profiles to control services. (by @arbrandes) --> | ||
- [Fix] Don't start Celery workers in dev mode, as they're never used. (by @arbrandes) --> | ||
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -170,6 +170,8 @@ services: | |
{%- endfor %} | ||
depends_on: | ||
- lms | ||
profiles: | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I wasn't familiar with profiles, to be honest. I like the idea of not running workers in dev, but I'd like to avoid making a breaking change to the filter API, and also changes across many python functions. Instead, could we simply move the lms-worker and cms-worker declarations from docker-compose.yml to docker-compose.prod.yml? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I don't think it's going to be that simple. There are other places in the code that assume those service definitions exist. For instance, https://github.com/overhangio/tutor/blob/master/tutor/commands/compose.py#L289. Plus, I suspect profiles might be useful down the road, woudn't you say so? If you're dead set against it, though, there is another way: we can just set the worker services in the dev compose override file to a profile like "donotstart". We get the same thing this PR provides, but without actually supporting different profiles. |
||
- local | ||
|
||
cms-worker: | ||
image: {{ DOCKER_IMAGE_OPENEDX }} | ||
|
@@ -189,5 +191,7 @@ services: | |
{%- endfor %} | ||
depends_on: | ||
- cms | ||
profiles: | ||
- local | ||
|
||
{{ patch("local-docker-compose-services")|indent(2) }} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We would need some sort of guidelines to understand how the workers can be setup in dev mode, especially now that we are using docker compose profiles.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just a simple
tutor dev dc start lms-worker
would start the service, for instance, but the workers wouldn't be actually usable without modifying settings.py. Is this what you mean we should document?Of course, the other question would be: why would anybody want to do this in a dev environment?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, the command and setting changes, yes. I get the point that most devs might not be using this, we can have the doc in a followup. It is not a blocker.