1. 04 Mar, 2019 1 commit
  2. 01 Mar, 2019 7 commits
  3. 28 Feb, 2019 7 commits
  4. 27 Feb, 2019 1 commit
  5. 26 Feb, 2019 2 commits
  6. 22 Feb, 2019 6 commits
  7. 21 Feb, 2019 3 commits
  8. 20 Feb, 2019 1 commit
  9. 18 Feb, 2019 1 commit
    • Alain Takoudjou's avatar
      plugin recipe: improve recipe to correctly generate promise which has complex parameters · b53ba563
      Alain Takoudjou authored
      Use json.dumps/.loads to generate promise plugin code. This is safe as it will correctly escape sring and prevent code injection from untrustable parameters.
      Add 'import' parameter to simplify parameters used to generate the script instead of passing full import code. When import parameter is set, promise will be loaded from that import path and parameter `content` is ignored.
      /reviewed-on !515
  10. 15 Feb, 2019 3 commits
  11. 14 Feb, 2019 2 commits
  12. 12 Feb, 2019 1 commit
  13. 10 Feb, 2019 2 commits
  14. 08 Feb, 2019 3 commits
    • Guillaume Hervier's avatar
      software/kvm: Add buildout.hash.cfg and refactor software sections. · 1707af40
      Guillaume Hervier authored
      - Add `buildout.hash.cfg` file so this way we can use the useful `update-hash` script
      - Refactor a bit the `software.cfg` file sections as it was repeating itself
      /reviewed-on !512
    • Łukasz Nowak's avatar
      caddy-frontend: Test try_duration and try_interval · 26900109
      Łukasz Nowak authored
      Extend the backend with Timeout configuration via headers and use it
      to prove, that request taking more than try_duration is correctly served.
      Also prove that try_duration and try_interval are correct passed to the slave
    • Łukasz Nowak's avatar
      caddy-frontend: Fix random 502 EOFs by adding try_duration · 4f168972
      Łukasz Nowak authored
      try_duration and try_interval are Caddy proxy's switches which allow to deal
      with non working backend (https://caddyserver.com/docs/proxy)
      The non working backend is the one, to which connection is lost or was not
      possible to make, without sending any data.
      The default try_duration=5s and try_interval=250ms are chosen, so that in
      normal network conditions (with all possible problems in the network, like
      lost packets) the browser will have to wait up to 5 seconds to be informed
      that backend is inaccessible or for the request to start being processed,
      but only a bit more than 250ms if Caddy would have to reestablish connection
      to faulty backend.
      In order to check it out it is advisable to setup a system, with real backend,
      like apache one, and configure iptables to randomly reject packets to it:
        iptables -A INPUT -m statistic --mode random -p tcp --dport <backend_port> \
        --probability 0.05 -j REJECT --reject-with tcp-reset
      Using ab or any other tool will results with lot of 502 EOF in the Caddy error
      log and also reported by ab. With this configuration there are no more
      errors visible to the client, which come from the problems on the network
      between Caddy and the backend.