1. 15 Jan, 2015 6 commits
  2. 13 Jan, 2015 2 commits
  3. 12 Jan, 2015 5 commits
  4. 09 Jan, 2015 1 commit
  5. 08 Jan, 2015 6 commits
  6. 07 Jan, 2015 3 commits
  7. 06 Jan, 2015 1 commit
  8. 05 Jan, 2015 1 commit
    • Kirk Webb's avatar
      Enforce permissions for dataset leases at mapping time. · bedcb609
      Kirk Webb authored
      * Swapper must have appropriate level of access (RO or RW).
      * If RO is requested, dataset must not be in use RW.
      * If RW is requested, dataset must not be in use at all.
      
      Also relaxed the checks in the parser; it was considering dynamic lease
      state, which isn't the right thing to do there.
      bedcb609
  9. 29 Dec, 2014 1 commit
  10. 22 Dec, 2014 2 commits
  11. 12 Dec, 2014 1 commit
  12. 10 Dec, 2014 2 commits
  13. 09 Dec, 2014 3 commits
  14. 08 Dec, 2014 2 commits
  15. 07 Dec, 2014 2 commits
  16. 05 Dec, 2014 1 commit
    • 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
  17. 03 Dec, 2014 1 commit
    • 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