1. 17 Aug, 2018 1 commit
  2. 16 Aug, 2018 3 commits
  3. 15 Aug, 2018 3 commits
  4. 14 Aug, 2018 1 commit
  5. 10 Aug, 2018 1 commit
  6. 08 Aug, 2018 1 commit
    • David Johnson's avatar
      Add Docker container blockstore support. · 9bf09981
      David Johnson authored
      Docker containers may be (and default to, and in the shared host case,
      must be) deprivileged; thus, they cannot mount devices, much less tell
      the kernel (via iscsi userspace tools, etc) to make devices.
      
      Therefore, we must setup any storage backing devices (temp LVs, iscsi
      attachments) outside the container.  This commit makes that possible for
      rc.storage and linux liblocstorage.  Basically, rc.storage now supports
      (for the Linux liblocstorage and Docker) the -j vnodeid calling
      convention; and if it's being called on behalf of a vnodeid, it uses
      per-vnodeid fstab for any mounts, storage.conf for its state; etc.
      
      I modified libvnode_docker to *not* create virtual networks for
      remote blockstore links, because those are pinned to /30s, and thus I
      have no client blockstore link address to place on a device in the root
      context.  However, I (ab)used the existing Docker network setup for the
      blockstore links, and that all happens the same as it used to; we just
      no longer create the Docker virtual network nor attach the container to
      it.
      
      Finally, I modified tmcd dostorageconfig slightly to return
      HOSTIP/HOSTMASK for remote blockstores; and now
      libsetup::getstorageconfig will use HOSTIP in preference to its own
      HOSTID->HOSTIP translation.  I had to do this so that libvnode_docker in
      the root context would not have to go through the mess of translating
      HOSTID on behalf of a vnode.
      9bf09981
  7. 07 Aug, 2018 1 commit
  8. 06 Aug, 2018 2 commits
    • David Johnson's avatar
      Fix a couple minor Docker clientside bugs. · 2a9160f0
      David Johnson authored
      2a9160f0
    • David Johnson's avatar
      In docker image emulabization, attempt to combine COPY instructions. · 18361092
      David Johnson authored
      We now try to emulate any simple COPY <src> <dst> instructions via rsync
      prior to image build.
      
      This *does* mean that artifact builder scripts must be careful to create
      all necessary dirs according to the base image semantics, because the
      base image content is not there when we emulate the COPY instructions.
      For instance, many of the modified Dockerfile-runit and
      runit-artifacts.sh files depended on built runit packages being
      installed into /tmp in the final image -- but they didn't create the
      /tmp dir because the COPY instruction they used was running atop a
      fully-populated base image that already had /tmp.  Thus, the
      runit-artifacts.sh scripts had to be changed to create /tmp with the
      proper permissions.
      18361092
  9. 30 Jul, 2018 5 commits
  10. 27 Jul, 2018 1 commit
  11. 25 Jul, 2018 1 commit
  12. 24 Jul, 2018 2 commits
  13. 20 Jul, 2018 4 commits
  14. 17 Jul, 2018 2 commits
  15. 16 Jul, 2018 3 commits
  16. 07 Jul, 2018 4 commits
  17. 29 Jun, 2018 1 commit
  18. 21 Jun, 2018 1 commit
  19. 20 Jun, 2018 1 commit
    • David Johnson's avatar
      Bring iperf-2.0.2 up to speed for gccs up through 8.x. · 8bd8d4c7
      David Johnson authored
      Unfortunately, I didn't notice the first time, but the include causing
      all the problems was an apparently unnecessary math.h.  Simply removing
      it fixed all the odd libstdc++ errors; trying to fix them all up and
      leaving it in was much more complicated.  This works on gccs 4, 6, 7, 8.
      
      This is a good outcome because the iperf-2.0.10 patch is still subtly
      wrong in some important way; bandwidths are inconsistent or sometimes
      consistently asymmetric (with no good reason).  So some parameter must
      still not be being exchanged between client and server.
      8bd8d4c7
  20. 15 Jun, 2018 1 commit
    • David Johnson's avatar
      Fix doubly-run ntp on Ubuntu 14. · a2c69a18
      David Johnson authored
      /etc/init.d/ntp was being run twice on Ubuntu14 (and was failing slowly
      the first time) because of the presence of
      /etc/network/if-up.d/ntpdate... which would run ntpdate then
      /etc/init.d/ntp via invoke-rc.d... so we would see a double start with
      lots of delay.
      
      So now we overwrite that hook script!  Ugh.
      a2c69a18
  21. 12 Jun, 2018 1 commit