Skip to content
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

Question: Mount config on docker run #99

Open
arnesetzer opened this issue Aug 7, 2024 · 1 comment
Open

Question: Mount config on docker run #99

arnesetzer opened this issue Aug 7, 2024 · 1 comment

Comments

@arnesetzer
Copy link
Contributor

Is there a specific reason why the config.yaml is "baked in" into the docker image, but the data is not? Since make run loads the datasets dynamically, I was wondering why the config file is, more or less, static.

Building on the question: What's your opinion on a PR which makes it possible to load the config.yaml dynamically as the data?

@ajnisbet
Copy link
Owner

Good idea!

Because opentopodata uses caching both in memcached and in the python process's memory between requests, the safest thing to do would be to kill both uwsgi (which manages python) and memcached like this:

  • A new service in docker/supervisord.conf that watches for changes in config.yaml and example-config.yaml using something like watchdog
  • If the config file has changed:
    • Gracefully stop uwsgi
    • Wipe memcached
    • Start uwsgi (which will pull in the new config)
    • Run the warm_cache service

This is basically the same as what make build; make run would do. But at least you don't have to trigger it manually.

It would be nicer in theory to do something like only reloading the datasets that were changed in the config instead of nuking everything. This would speed up reloads! But I fear that the selective cache invalidation of that approach would be threaten the reliability of the software.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants