Skip to content
Snippets Groups Projects
  1. Jul 14, 2021
  2. Jul 08, 2021
  3. Jun 17, 2021
  4. Jun 07, 2021
  5. May 24, 2021
  6. May 05, 2021
  7. 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
    • Andrew Morgan's avatar
      Add note to docker docs explaining platform support (#9801) · f16c6cf5
      Andrew Morgan authored
      Context is in https://github.com/matrix-org/synapse/issues/9764#issuecomment-818615894.
      
      I struggled to find a more official link for this. The problem occurs when using WSL1 instead of WSL2, which some Windows platforms (at least Server 2019) still don't have. Docker have updated their documentation to paint a much happier picture now given WSL2's support.
      
      The last sentence here can probably be removed once WSL1 is no longer around... though that will likely not be for a very long time.
      f16c6cf5
  8. Apr 08, 2021
  9. Mar 30, 2021
  10. Mar 26, 2021
  11. Mar 25, 2021
  12. Mar 22, 2021
  13. Mar 16, 2021
  14. Feb 22, 2021
  15. Feb 15, 2021
  16. Jan 29, 2021
  17. Jan 19, 2021
  18. Jan 12, 2021
    • Dan Callahan's avatar
      Fix failures in Debian packaging (#9079) · fa6deb29
      Dan Callahan authored
      Debian package builds were failing for two reasons:
      
       1. Python versions prior to 3.7 throw exceptions when attempting to print
          Unicode characters under a "C" locale. (#9076)
      
       2. We depended on `dh-systemd` which no longer exists in Debian Bullseye, but
          is necessary in Ubuntu Xenial. (#9073)
      
      Setting `LANG="C.UTF-8"` in the build environment fixes the first issue.
      See also: https://bugs.python.org/issue19846
      
      
      
      The second issue is a bit trickier. The dh-systemd package was merged into
      debhelper version 9.20160709 and a transitional package left in its wake.
      
      The transitional dh-systemd package was removed in Debian Bullseye.
      
      However, Ubuntu Xenial ships an older debhelper, and still needs dh-systemd.
      
      Thus, builds were failing on Bullseye since we depended on a package which had
      ceased existing, but we couldn't remove it from the debian/control file and our
      build scripts because we still needed it for Ubuntu Xenial.
      
      We can fix the debian/control issue by listing dh-systemd as an alternative to
      the newer versions of debhelper. Since dh-systemd declares that it depends on
      debhelper, Ubuntu Xenial will select its older dh-systemd which will in turn
      pull in its older debhelper, resulting in no change from the status quo. All
      other supported releases will satisfy the debhelper dependency constraint and
      skip the dh-systemd alternative.
      
      Build scripts were fixed by unconditionally attempting to install dh-systemd on
      all releases and suppressing failures.
      
      Once we drop support for Ubuntu Xenial, we can revert most of this commit and
      rely on the version constraint on debhelper in debian/control.
      
      Fixes #9076
      Fixes #9073
      
      Signed-off-by: default avatarDan Callahan <danc@element.io>
      fa6deb29
  19. Dec 09, 2020
  20. Dec 04, 2020
    • Jordan Bancino's avatar
      Remove version pin prometheus_client dependency (#8875) · 295c209c
      Jordan Bancino authored
      This removes the version pin of the `prometheus_client` dependency, in direct response to #8831. If merged, this will close #8831 
      
      As far as I can tell, no other changes are needed, but as I'm no synapse expert, I'm relying heavily on CI and maintainer reviews for this. My very primitive test of synapse with prometheus_client v0.9.0 on my home server didn't bring up any issues, so we'll see what happens.
      
      Signed-off-by: Jordan Bancino
      295c209c
  21. Nov 17, 2020
  22. Nov 02, 2020
  23. Oct 11, 2020
  24. Oct 09, 2020
  25. Aug 26, 2020
  26. Aug 24, 2020
  27. 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
  28. Jul 17, 2020
  29. Jul 06, 2020
  30. Jun 03, 2020
  31. May 22, 2020
  32. May 19, 2020
  33. May 03, 2020
  34. Feb 18, 2020
  35. Feb 12, 2020
  36. Nov 22, 2019
Loading