1. 10 Dec, 2014 6 commits
  2. 09 Dec, 2014 11 commits
  3. 08 Dec, 2014 4 commits
  4. 07 Dec, 2014 3 commits
  5. 06 Dec, 2014 1 commit
  6. 05 Dec, 2014 9 commits
    • Leigh B Stoller's avatar
      4559fe46
    • Mike Hibler's avatar
      Mike's quick fix for an image creation problem. · d96333e3
      Mike Hibler authored
      Leigh should do this right!
      d96333e3
    • Mike Hibler's avatar
      Support dynamically created NFS-root filesystems for admin MFS. · f36bcfab
      Mike Hibler authored
      Significant hackary involved. Similar to exports_setup, there is a boss-side
      script and an ops-side script to handle creation and destruction of the ZFS
      clones that are used for the NFS filesystem. The rest was all about when to
      invoke said scripts.
      
      Creation is easy, we just do a clone whenever the TBAdminMfsSelect is called
      to "turn on" node admin mode. Destruction is not so simple. If we destroyed
      the clone on the corresponding TBAdminMfsSelect "off" call, then we could
      yank the filesystem out from under the node if it was still running in the
      MFS (e.g., "node_admin -n off node"). While that would probably be okay in
      most uses, where at worst we would have to apod or power cycle the node, we
      try to do better. TBAdminMfsSelect "off" instead just renames the clone
      (to "<nodeid>-DEAD") so that it stays available if the node is running on
      it at the time, but ensures that it will not get accidentally used by any
      future boot. We check for, and destroy, any previous versions for a node
      every time we invoke the nfsmfs_setup code for that node. We also destroy
      live or dead clones whenever we call nfree. This ensures that all MFSes
      get cleaned up at experiment swapout time.
      f36bcfab
    • Leigh B Stoller's avatar
      Dataset fixes. · 1f0cdf67
      Leigh B Stoller authored
      1f0cdf67
    • Leigh B Stoller's avatar
      Turn on dataset UI for studly users. · 3059271b
      Leigh B Stoller authored
      3059271b
    • Leigh B Stoller's avatar
      c2d1da65
    • Leigh B Stoller's avatar
      70e4560e
    • Leigh B Stoller's avatar
      More image version fixes and changes. · 3802c0dc
      Leigh B Stoller authored
      1. Fixes to allow specific versions of images to be exported; the existing
         path was reverting back to the highest numbered version. So far this has
         not come up, but will with APT and Cloud.
      
      2. Add version argument to image_metadata.php, mostly as a convenience. So
         rather then using the version specific uuid, you can use the image uuid,
         with a version argument. This is actually more sensible, except for one
         important fact; it is not possible to locate a deleted image this way,
         since the image descriptor is gone (only the version descriptors are in
         the DB).
      
         But I went ahead and did it cause there is still some question as to
         whether we care about being able to export a deleted image. We do not
         expose these URLs at this time, but you can use one.
      3802c0dc
    • Leigh B Stoller's avatar
      Allow failure action in node: · 62a0f9ad
      Leigh B Stoller authored
          <emulab:failure_action action="nonfatal"/>
      62a0f9ad
  7. 04 Dec, 2014 4 commits
  8. 03 Dec, 2014 2 commits
    • Mike Hibler's avatar
      Report both PXEBOOTING/BOOTING events on PXE-originated DHCP request. · 25f775fe
      Mike Hibler authored
      A concession to performance. Previously, PXEBOOTING was reported on
      the PXE DHCP request and BOOTING on the following OS-originated request.
      This is conceptually ideal, as that is what those states were intended
      to mean, but it causes two synchronous "reportboot" command executions
      from dhcpd for every node boot. Worse, the time gap between the second,
      OS-originated DHCP call and the first explicit state reported by the
      node itself (e.g., TBSETUP or RELOADSETUP) is generally small enough
      that the node reported state often arrived at stated before the BOOTING
      state from dhcpd. This can cause excess node reboots or other undesirable
      behaviors from stated.
      
      So now we only invoke "reportboot" on the first PXE-originated call and
      tell reportboot to send both PXEBOOTING and BOOTING events at that time.
      This does not eliminate the race condition above, but makes it unlikely
      as there is the whole kernel boot process (10s of seconds) between the
      dhcpd state reports and the first node state report.
      25f775fe
    • Leigh B Stoller's avatar
      Change default cluster to APT. · 31b04b4d
      Leigh B Stoller authored
      31b04b4d