Skip to content
Snippets Groups Projects
  1. Nov 23, 2021
    • Shay's avatar
      Remove code invalidated by deprecated config flag... · 7cebaf96
      Shay authored
      Remove code invalidated by deprecated config flag 'trust_identity_servers_for_password_resets' (#11395)
      
      * remove background update code related to deprecated config flag
      
      * changelog entry
      
      * update changelog
      
      * Delete 11394.removal
      
      Duplicate, wrong number
      
      * add no-op background update and change newfragment so it will be consolidated with associated work
      
      * remove unused code
      
      * Remove code associated with deprecated flag from legacy docker dynamic config file
      
      Co-authored-by: default avatarreivilibre <oliverw@matrix.org>
      7cebaf96
  2. Aug 17, 2021
  3. Jun 17, 2021
  4. May 24, 2021
  5. Apr 14, 2021
    • Andrew Morgan's avatar
      Add a dockerfile for running a set of Synapse worker processes (#9162) · 7e460ec2
      Andrew Morgan authored
      This PR adds a Dockerfile and some supporting files to the `docker/` directory. The Dockerfile's intention is to spin up a container with:
      
      * A Synapse main process.
      * Any desired worker processes, defined by a `SYNAPSE_WORKERS` environment variable supplied at runtime.
      * A redis for worker communication.
      * A nginx for routing traffic.
      * A supervisord to start all worker processes and monitor them if any go down.
      
      Note that **this is not currently intended to be used in production**. If you'd like to use Synapse workers with Docker, instead make use of the official image, with one worker per container. The purpose of this dockerfile is currently to allow testing Synapse in worker mode with the [Complement](https://github.com/matrix-org/complement/) test suite.
      
      `configure_workers_and_start.py` is where most of the magic happens in this PR. It reads from environment variables (documented in the file) and creates all necessary config files for the processes. It is the entrypoint of the Dockerfile, and thus is run any time the docker container is spun up, recreating all config files in case you want to use a different set of workers. One can specify which workers they'd like to use by setting the `SYNAPSE_WORKERS` environment variable (as a comma-separated list of arbitrary worker names) or by setting it to `*` for all worker processes. We will be using the latter in CI.
      
      Huge thanks to @MatMaul for helping get this all working :tada: This PR is paired with its equivalent on the Complement side: https://github.com/matrix-org/complement/pull/62.
      
      Note, for the purpose of testing this PR before it's merged: You'll need to (re)build the base Synapse docker image for everything to work (`matrixdotorg/synapse:latest`). Then build the worker-based docker image on top (`matrixdotorg/synapse:workers`). 
      7e460ec2
  6. Mar 30, 2021
  7. Feb 22, 2021
  8. Jan 19, 2021
  9. Oct 09, 2020
  10. Aug 11, 2020
    • Erik Johnston's avatar
      Move setting of Filter into code. · 0304ad0c
      Erik Johnston authored
      We do this to prevent foot guns. The default config uses a MemoryFilter,
      but users are free to change to logging to files directly. If they do
      then they have to ensure to set the `filters: [context]` on the right
      handler, otherwise records get written with the wrong context.
      
      Instead we move the logic to happen when we generate a record, which is
      when we *log* rather than *handle*.
      
      (It's possible to add filters to loggers in the config, however they
      don't apply to descendant loggers and so they have to be manually set on
      *every* logger used in the code base)
      0304ad0c
  11. Oct 18, 2019
  12. Jul 12, 2019
  13. Jul 03, 2019
  14. Jun 27, 2019
  15. Jun 25, 2019
  16. Feb 11, 2019
  17. Feb 05, 2019
  18. Jan 22, 2019
  19. Dec 04, 2018
  20. Nov 20, 2018
  21. Oct 25, 2018
  22. Oct 17, 2018
    • Richard van der Hoff's avatar
      Ship the email templates as package_data · 15195729
      Richard van der Hoff authored
      move the example email templates into the synapse package so that they can be
      used as package data, which should mean that all of the packaging mechanisms
      (pip, docker, debian, arch, etc) should now come with the example templates.
      
      In order to grandfather in people who relied on the templates being in the old
      place, check for that situation and fall back to using the defaults if the
      templates directory does not exist.
      15195729
  23. Sep 16, 2018
  24. Aug 02, 2018
Loading