1. 07 May, 2018 4 commits
  2. 06 May, 2018 2 commits
  3. 05 May, 2018 4 commits
  4. 04 May, 2018 3 commits
  5. 03 May, 2018 5 commits
  6. 25 Apr, 2018 2 commits
  7. 24 Apr, 2018 1 commit
  8. 19 Apr, 2018 1 commit
  9. 18 Apr, 2018 2 commits
    • David Johnson's avatar
      7b8f84c0
    • Elijah Grubb's avatar
      Emulab Docker CMD and Entrypoint to runit services · eebbe96f
      Elijah Grubb authored
      This adds to the preparation of Docker images running
      on the Emulab system by creating a new runit service
      handling the details of their CMD and Entrypoint capabilities.
      This scripting also sets the scaffolding for custom
      CMDs and environment variables to be set by the user
      as a part of their profile parameters.
      
      Squashed commit of the following:
      
      commit 50ad95137f138f663ff826a16857911296686cf6
      Merge: 24f72ab86 38f254fd
      Author: Elijah Grubb <u0894728@utah.edu>
      Date:   Wed Apr 18 03:35:09 2018 -0600
      
          Merge branch 'master' into docker-entrypoint
      
      commit 24f72ab86ae9ef2cf91af57279bcc4fa0ce50d9c
      Author: Elijah Grubb <u0894728@utah.edu>
      Date:   Wed Apr 4 02:30:10 2018 -0600
      
          Implemented piping of docker profile parameters
      
      commit 52ad871ba22fb90af374baa1fb951210fbb1c0be
      Merge: ce34a36c1 b4679058
      Author: Elijah Grubb <u0894728@utah.edu>
      Date:   Wed Mar 28 10:01:45 2018 -0600
      
          Merge remote-tracking branch 'origin/master' into docker-entrypoint
      
      commit ce34a36c17ad0654bc52c075a4c52fe330eb6e35
      Author: Elijah Grubb <u0894728@utah.edu>
      Date:   Mon Mar 26 08:49:15 2018 -0600
      
          Implemented runit service for docker entrypoint
      eebbe96f
  10. 11 Apr, 2018 4 commits
    • Leigh B Stoller's avatar
      Stated headaches. · 7f90bc5c
      Leigh B Stoller authored
      7f90bc5c
    • Leigh B Stoller's avatar
      Need to apply this patch during the ONIE dongle install. This fixes · aacb61a1
      Leigh B Stoller authored
      the problem with FTOS using a different MAC address for DHCP then
      ONIE does.
      aacb61a1
    • Leigh B Stoller's avatar
      A few more tweaks to ONIE clientside. · 7520e9a8
      Leigh B Stoller authored
      7520e9a8
    • Leigh B Stoller's avatar
      Initial checkin of ONIE clientside. · 72d6a8e6
      Leigh B Stoller authored
      * Add onie-dongle and onie-dongle-install targets, which builds and
        installs (DESTDIR required) the bits and pieces we need. This install
        is intended to update the initram FS. ONIE operates as the admin MFS
        and the "frisbee" MFS, bootinfoclient used to emulate PXEWAIT
        waitmode.
      
      * Need to be build in the ONIE cross compiler environment, see the
        ftos.env and mlnx.env for the environment variables before config and
        build.
      
      * Basic operation is like the old CDROM; use bootinfoclient and tmcc
        bootwhat to drop into "admin" or "frisbee" mode, or boot the NOS. Use
        tmcc loadinfo and call onie-nos-install. Use a grub environment
        variable to tell grub to either boot the NOS (and then clear the
        variable) or boot into ONIE.
      72d6a8e6
  11. 05 Apr, 2018 1 commit
  12. 02 Apr, 2018 2 commits
    • Leigh B Stoller's avatar
      b13459fe
    • David Johnson's avatar
      Fix a race in kill/restart of pubsubd in rc.bootsetup . · a3b1a555
      David Johnson authored
      pubsubd wasn't restarting, surely because the existing pubsubd was still
      running and/or socket state was still live in the kernel even after
      putative death.  This took a long time to manifest, and it's not clear
      exactly what the problem was, but making sure pubsubd is dead (and is no
      longer holding its specific port) is appropriate even if we assume
      REUSEADDR is working, and fixes the current problem.  This was only
      observable on the pc3000s and c220g2s, as far as I saw.
      a3b1a555
  13. 30 Mar, 2018 2 commits
    • Mike Hibler's avatar
      Install the right file Mike.. · 396431a0
      Mike Hibler authored
      396431a0
    • Mike Hibler's avatar
      Support for frisbee direct image upload to fs node. · 99943a19
      Mike Hibler authored
      We have had issues with uploading images to boss where they are then written
      across NFS to ops. That seems to be a network hop too far on CloudLab Utah
      where we have a 10Gb control network. We get occasional transcient timeouts
      from somewhere in the TCP code. With the convoluted path through real and
      virtual NICs, some with offloading, some without, packets wind up getting
      out of order and someone gets far enough behind to cause problems.
      
      So we work around it.
      
      If IMAGEUPLOADTOFS is defined in the defs-* file, we will run a frisbee
      master server on the fs (ops) node and the image creation path directs the
      nodes to use that server. There is a new hack configuration for the master
      server "upload-only" which is extremely specific to ops: it validates the
      upload with the boss master server and, if allowed, fires up an upload
      server for the client to talk to. The image will thus be directly uploaded
      to the local (ZFS) /proj or /groups filesystems on ops. This seems to be
      enough to get around the problem.
      
      Note that we could allow this master server to serve downloads as well to
      avoid the analogous problem in that direction, but this to date has not
      been a problem.
      
      NOTE: the ops node must be in the nodes table in the DB or else boss will
      not validate proxied requests from it. The standard install procedure is
      supposed to add ops, but we have a couple of clusters where it is not in
      the table!
      99943a19
  14. 29 Mar, 2018 2 commits
  15. 27 Mar, 2018 1 commit
  16. 26 Mar, 2018 3 commits
  17. 22 Mar, 2018 1 commit
    • Mike Hibler's avatar
      Bug fix: attempt to avoid hangs when creating blockstores on large SSDs. · a670b802
      Mike Hibler authored
      At least I think the problem is that we are doing inadvertent TRIM
      operations on large (480GB) SSDs. For one, when creating an ext4
      filesystem on such a blockstore, we specify "nodiscard". I toyed
      with the idea of turning off "issue_discards" for the lvremove
      operations when a blockstore is destroyed, but that led to old
      metadata being seen when the blockstore was re-created. That led
      to the last change, which was to force metadata zeroing when we
      do an lvcreate of a blockstore.
      a670b802