1. 11 Jan, 2021 7 commits
    • Zygmunt Krynicki's avatar
      Remove unreachable code · 909f078c
      Zygmunt Krynicki authored
      
      
      All the lines are reported by go vet, as of version 1.15.6:
      
          # github.com/snapcore/spread/spread
          spread/logger.go:146:12: assignment copies lock value to *Logger: log.Logger contains sync.Mutex
          spread/client.go:132:2: unreachable code
          spread/client.go:307:2: unreachable code
          spread/client.go:743:2: unreachable code
          spread/google.go:551:2: unreachable code
          spread/google.go:754:2: unreachable code
          spread/linode.go:1130:2: unreachable code
      Signed-off-by: Zygmunt Krynicki's avatarZygmunt Krynicki <zygmunt.krynicki@huawei.com>
      909f078c
    • Zygmunt Krynicki's avatar
      Do not copy log.Logger and the contained sync.Mutex · ade6e038
      Zygmunt Krynicki authored
      
      
      Go vet reports the following problem:
      
          # github.com/snapcore/spread/spread
          spread/logger.go:135:13: assignment copies lock value to logSaved: log.Logger contains sync.Mutex
          spread/logger.go:142:12: assignment copies lock value to *Logger: log.Logger contains sync.Mutex
          spread/logger.go:146:12: assignment copies lock value to *Logger: log.Logger contains sync.Mutex
      
      Cursory inspection of the termLock and termUnlock functions performing this
      overwrite indicates that it is to restore the flags, prefix and the io.Writer
      used by the logger internally. Analysis of the go 1.13 source code indicates
      that there's very little other state:
      
          type Logger struct {
              mu     sync.Mutex // ensures atomic writes; protects the following fields
              prefix string     // prefix to write at beginning of each line
              flag   int        // properties
              out    io.Writer  // destination for output
              buf    []byte     // for accumulating text to write
          }
      
      Instead of writing over the whole struct, save and restore individual fields.
      Globally only the io.Writer needs to be saved across termLock and termUnlock
      calls. Inside termUnlock, flags and prefix are also saved and restore around
      the internal "flush".
      Signed-off-by: Zygmunt Krynicki's avatarZygmunt Krynicki <zygmunt.krynicki@huawei.com>
      ade6e038
    • Zygmunt Krynicki's avatar
      Display go version · ea7c37af
      Zygmunt Krynicki authored
      
      Signed-off-by: Zygmunt Krynicki's avatarZygmunt Krynicki <zygmunt.krynicki@huawei.com>
      ea7c37af
    • Zygmunt Krynicki's avatar
      Add go.mod describing all dependencies. · 18370657
      Zygmunt Krynicki authored
      
      
      This also spells out the import path to be github.com/snapcore/spread.
      Signed-off-by: Zygmunt Krynicki's avatarZygmunt Krynicki <zygmunt.krynicki@huawei.com>
      18370657
    • Zygmunt Krynicki's avatar
      Switch to gopkg.in/yaml.v3 · 6d05f0ea
      Zygmunt Krynicki authored
      
      
      In order to improve friendliness to downstream pakaging, use stable libraries
      and unify behind a single version, switch humbox to yaml.v3. The ynext version
      is unsupported and yaml.v3 was tagged and released. An earlier discussion with
      Gustavo indicates that yaml.v3 is the right version to use.
      Signed-off-by: Zygmunt Krynicki's avatarZygmunt Krynicki <zygmunt.krynicki@huawei.com>
      6d05f0ea
    • Zygmunt Krynicki's avatar
      Add initial CI pipeline · cf10bf57
      Zygmunt Krynicki authored
      
      Signed-off-by: Zygmunt Krynicki's avatarZygmunt Krynicki <zygmunt.krynicki@huawei.com>
      cf10bf57
    • Zygmunt Krynicki's avatar
      Explain oh-spread fork · 2350e1ae
      Zygmunt Krynicki authored
      
      
      The principle are that:
      
      1. original import paths are retained
      2. features and fixes will be upstreamed
      3. oh-spread and upstream spread move on separate timelines
      
      Upstream discussions may be slow. The friendly fork is happy to carry delta for
      as long as necessary.
      Signed-off-by: Zygmunt Krynicki's avatarZygmunt Krynicki <zygmunt.krynicki@huawei.com>
      2350e1ae
  2. 15 May, 2020 2 commits
  3. 03 Mar, 2020 5 commits
  4. 13 Feb, 2020 2 commits
  5. 11 Dec, 2019 1 commit
  6. 23 Oct, 2019 1 commit
    • Zygmunt Krynicki's avatar
      tests: fix ad-hoc test (#92) · 8fa71c9d
      Zygmunt Krynicki authored
      This branch fixes the ad-hoc test which can fail on hand-crafted parsing of .spread-reuse.yaml.
      The parsing was made to be more robust with Python.
      8fa71c9d
  7. 18 Oct, 2019 1 commit
  8. 25 Sep, 2019 3 commits
  9. 26 Aug, 2019 2 commits
  10. 19 Jul, 2019 2 commits
  11. 30 Aug, 2018 1 commit
  12. 20 Aug, 2018 1 commit
  13. 16 Aug, 2018 1 commit
    • Michael Vogt's avatar
      spread: run MATCH in a subshell (#67) · 2d0b4ae3
      Michael Vogt authored
      We ran into a confusing error when using MATCH in one of our snapd
      tests. It runs out the issue can be reproduced with:
      ```
      MATCH () {
          {
              set +ux
          } 2> /dev/null;
          return 0
      }
      MATCH foo <<< foo
      test 1 -eq 2
      ```
      When this is used, the output is:
      ```
      $ bash -eux reproducer.sh
      + MATCH foo
      ```
      I.e. the test line is not displayed.
      
      It turns out the reason is that the MATCH function uses "set +ux"
      which turns off the traces globally. When MATCH is used in a
      pipe (e.g. "echo foo | MATCH foo") then MATCH is run in a
      subshell and the turning off is not criticial. However when
      using with here strings for file redirects and no subshell
      is used turning off trace globally is an issue. The fix is
      simply to run MATCH always in a subshell.
      2d0b4ae3
  14. 27 Jul, 2018 1 commit
    • Michael Vogt's avatar
      client: simplify MATCH by using "<<<" (#65) · 54b30420
      Michael Vogt authored
      With SIGPIPE and "echo | grep -q" there is a race condition. If
      grep exists before echo is finished writing data then echo will
      get a SIGPIPE and this makes MATCH fail (which is very obscure
      to the user). To fix this this PR switch to the "<<<" HERE
      string (thanks to Chipaca).
      54b30420
  15. 05 Jul, 2018 1 commit
  16. 04 Jul, 2018 4 commits
    • Gustavo Niemeyer's avatar
      070a7c44
    • Gustavo Niemeyer's avatar
    • Michael Vogt's avatar
      client: fix dial on reboot when host is down (#61) · 154f10f6
      Michael Vogt authored
      The PR#53 broke the timeout handling in dialOnReboot. The
      current code has some problems, especially when the target
      does not survive the reboot (e.g. no working network after
      the reboot):
      
      - it will try to ssh.Dial the target and never timeouts
      - it will try to get uptime and on error retry forever
      - ssh.Dial is really doing the 5s timeout, on my system its
        more like 60s
      - This means that the timeout, relog and retry channel all
        can have data in which case golang picks a random channel.
      - This means on timeout in the worst case there is only a 1/3
        chance that the timeout channel is handled which may lead
        to much longer kill-timeouts (because ssh.Dial() takes ~60sec
        for me).
      
      I would love to write a test for this, I think we need to mock
      ssh.Dial for this particular test and ideally getUptime as
      well. I will do a followup with this as it will be slightly
      more involved.
      154f10f6
    • Gustavo Niemeyer's avatar
      google: avoid double-slash in URLs · 994a02f8
      Gustavo Niemeyer authored
      994a02f8
  17. 02 Jul, 2018 2 commits
    • Michael Vogt's avatar
      f6cd2840
    • Michael Vogt's avatar
      client: fix dialOnReboot() if the remote does not reply · 29816ca0
      Michael Vogt authored
      The PR#53 broke the timeout handling in dialOnReboot(). The
      current code has some problems, especially when the target
      does not survive the reboot (e.g. no working network after
      the reboot):
      
      - it will try to ssh.Dial() the target and never timeouts
      - it will try to get uptime and on error retry forever
      - ssh.Dial() is really doing the 5s timeout, on my system its
        more like 60s
      - This means that the timeout, relog and retry channel all
        can have data in which case golang picks a random channel.
      - This means on timeout in the worst case there is only a 1/3
        chance that the timeout channel is handled which may lead
        to much longer kill-timeouts (because ssh.Dial() takes ~60sec
        for me).
      
      I would love to write a test for this, I think we need to mock
      ssh.Dial() for this particular test and ideally getUptime as
      well. I will do a followup with this as it will be slightly
      more involved.
      29816ca0
  18. 21 Jun, 2018 1 commit
  19. 20 Jun, 2018 2 commits
    • Gustavo Niemeyer's avatar
      google: polish garbage collection · 4aa6d56e
      Gustavo Niemeyer authored
      Some tweaks on the merged logic:
      
      - Don't duplicate instance type (googleServerData)
      - It really needs just Labels added
      - Preserve safety logic that only removes known labels
      - No default for halt-timeout.. the backend needs to specify
      - Don't split remove function unnecessarily
      - Tune list() function, making it similar to other backends
      - Don't print when nothing is evaluated for removal
      4aa6d56e
    • Sergio Cazzolato's avatar
      4e39d424