1. 08 Nov, 2017 1 commit
  2. 06 Nov, 2017 1 commit
  3. 29 Aug, 2017 1 commit
  4. 26 Aug, 2017 1 commit
  5. 29 Apr, 2017 1 commit
  6. 11 Jan, 2017 1 commit
  7. 10 Jan, 2017 1 commit
  8. 09 Jan, 2017 1 commit
  9. 24 Oct, 2016 1 commit
  10. 03 Oct, 2016 1 commit
  11. 29 Sep, 2016 1 commit
  12. 20 Sep, 2016 1 commit
    • Mike Hibler's avatar
      Initial support for ephemeral RW clones of persistent blockstores. · f98ab0e5
      Mike Hibler authored
      Using "set-rwclone" ala:
          set $bsobj [$ns blockstore]
          $bsobj set-lease "emulab-ops/bar"
          $bsobj set-node $node
          $bsobj set-rwclone 1
      in your NS file will create a clone of the indicated persistent blockstore.
      Somewhat limited in utility since you can only have one clone of a
      particular blockstore per experiment.
  13. 08 Sep, 2016 1 commit
  14. 12 Apr, 2016 1 commit
  15. 23 Dec, 2015 1 commit
  16. 21 Oct, 2015 1 commit
  17. 07 Oct, 2015 3 commits
  18. 13 Aug, 2015 1 commit
  19. 06 Aug, 2015 1 commit
  20. 05 Aug, 2015 1 commit
    • Mike Hibler's avatar
      Change API interface to connect via the node IP rather than "localhost". · 76ed860d
      Mike Hibler authored
      In the current FreeNAS, the only options for configuring the web server
      are to listen on a specific IP or to listen on INADDR_ANY. If you do the
      former, then you cannot connect via "localhost". If you do the latter,
      then any experiment with an iSCSI blockstore could connect (via its
      per-blockstore VLAN/subnet/IP). While authentication is required to
      connect, the latter still makes me nervous.
      Note that I didn't have to change the "Dave API" to not use localhost
      as it appears to hook in below the web server.
  21. 04 Aug, 2015 1 commit
    • Mike Hibler's avatar
      Support for FreeNAS 9.3. · 490d011a
      Mike Hibler authored
      This REPLACES FreeNAS 9.2 support. The two are incompatible.
      This new code uses the REST API whereever possible (i.e., when it is
      implemented and works). There is some client-side reorg going on too.
  22. 02 Jun, 2015 1 commit
  23. 28 Jan, 2015 1 commit
    • Mike Hibler's avatar
      Implement "plan 1" for dataset sharing: "ephemeral RO snapshots". · 7aefdaa1
      Mike Hibler authored
      You can now simultaneously RW and RO map a dataset because all the RO
      mappings use copies (clones) of a snapshot. Only a single RW mapping
      of course.
      When the RW mapping swaps out it automatically creates a new snapshot.
      So there is currently no user control over when a version of the dataset
      is "published", it just happens everytime you swapout an experiment with
      a RW mapping.
      A new RW mapping does not affect current RO mappings of course as they
      continue to use whatever snapshot they were created with. New RO mappings
      with get the most recent snapshot, which we currently track in the DB via
      the per-lease attribute "last_snapshot".
      You can also now declare a lease to be "exclusive use" by setting the
      "exclusive_use" lease attribute (via modlease). This means that it follows
      the old semantics of only one mapping at a time, whether it be RO or RW.
      This is an alternative to the "simultaneous_ro_datasets" sitevar which
      enforces the old behavior globally. Primarily, I put this attribute in to
      prevent an unexpected failure in the snapshot/clone path from wreaking
      havoc over time. I don't know if there is any value in exposing this to
      the user.
  24. 22 Jan, 2015 1 commit
  25. 21 Jan, 2015 1 commit
  26. 12 Jan, 2015 1 commit
  27. 09 Jan, 2015 4 commits
  28. 08 Jan, 2015 1 commit
    • Kirk Webb's avatar
      Backend support for simultaneous read-only dataset access. · 9b6e1a59
      Kirk Webb authored
      Any number of users/experiments can mount a given dataset (given that
      they have permission) in read-only mode.  Attempts to mount RW will
      fail if the dataset is currently in use.  Attempts to mount RO while
      the dataset is in use RW are also prohibited.
      Under the hood, iSCSI lease exports (targets) are now managed per-lease
      instead of per-experiment.  The set of authorized initiators (based
      on network) is manipulated as consumers come and go.  When the last
      consumer goes, the export is torn down. Likewise, if there are no
      current consumers, a new consumer will cause an iSCSI export to be
      created for the lease.
      Also included in this commit is a small tweak to implicit lease permissions.
  29. 09 Oct, 2014 1 commit
  30. 08 Oct, 2014 1 commit
    • Kirk Webb's avatar
      Fix vlan interface handling under FreeNAS 9. · d403580d
      Kirk Webb authored
      FreeNAS 9 has reached a new level of broken in its handling of network
      configuration. Essentially each time a vlan interface is added, or
      IP configuration is added, it wipes all existing vlan configurtion
      and recreates it from its database.  Worse, when IP addresses/aliases
      are removed, it completely shuts off all network interfaces and
      re-configures them from scratch. ALL interfaces.  All of them.
      Every last one. Even those that are not in scope for the current
      modification operation.
      So, we now do ALL network manipulation, including create/destroy
      vlan operations, behind FreeNAS's back.  As a consequence, FreeNAS's
      UI will often not show the actual network configuration - it will only
      list those things that have been set up statically through its
      interfaces (command line or UI).
  31. 02 Oct, 2014 1 commit
    • Mike Hibler's avatar
      FreeNAS 9 support, "improved" FreeNAS 8 support. · 23447d73
      Mike Hibler authored
      A clientside top-level "gmake freenas-tarball" will build everything and
      construct an appropriate tarball. You must either build on FreeBSD 8.3 or
      FreeBSD 9.2, depending on the version of FreeNAS you are targetting.
      This cannot be done native on the FreeNAS box! In part because there is
      no compiler there, but even if there was, the install target would wreak
      havoc on a full root filesystem; it assumes it is working on a skeleton
      FS with just the Emulab stuff in it.
      Mostly this commit is grotesque Makefile hacking due to our tragic
      client-side tmcc OS-specific directory structure. Hey, don't blame me!
      It was, um...okay DO blame me...
  32. 01 Oct, 2014 1 commit
    • David Johnson's avatar
      Make our FreeNAS CLI wrapper work for version 9.x . · d399c393
      David Johnson authored
      This wasn't too bad, but there were some model changes -- and a few
      Django/whatever changes.
      There are a few backwards-incompat changes to the CLI args for some
      commands; probably we can finesse that if it matters.