1. 16 Apr, 2015 2 commits
  2. 14 Apr, 2015 1 commit
  3. 10 Apr, 2015 2 commits
  4. 06 Apr, 2015 1 commit
  5. 01 Apr, 2015 1 commit
  6. 31 Mar, 2015 2 commits
  7. 26 Mar, 2015 1 commit
    • Kirk Webb's avatar
      Update Force10 module to dynamically determine size of PortSet vectors. · 8a20f444
      Kirk Webb authored
      It's clear from the various Force10 switches and firmware versions
      that we've seen now that the vlan membership PortSet bit
      vector size can vary widely.  This variation even happens between
      different versions of firmware on the same switch!  So, now we
      detect this dynamically when the backend force10 snmpit object is
      instantiated (in readifIndex()).
      8a20f444
  8. 25 Mar, 2015 1 commit
  9. 24 Mar, 2015 1 commit
    • Mike Hibler's avatar
      Hopefully eliminate race in exports_setup when waiting for mountd to finish. · 031b174c
      Mike Hibler authored
      Changed mountd to write the current timestamp into /var/run/mountd.ts
      whenever it has finished processing all exports files. So someone who
      HUPs/USR1s mountd can check and see when the timestamp changes.
      
      We use this in exports_setup.proxy to ensure we do not return before
      mountd has completed parsing and effecting changes. Since I am too lazy
      to check the before and after values of the timestamp, I just remove that
      file just before signalling, and then wait for it to reappear to signify
      that mountd is done.
      031b174c
  10. 18 Mar, 2015 1 commit
  11. 15 Mar, 2015 1 commit
  12. 13 Mar, 2015 1 commit
  13. 09 Mar, 2015 1 commit
  14. 05 Mar, 2015 2 commits
  15. 20 Feb, 2015 1 commit
  16. 12 Feb, 2015 1 commit
  17. 09 Feb, 2015 1 commit
  18. 04 Feb, 2015 2 commits
  19. 03 Feb, 2015 1 commit
  20. 02 Feb, 2015 1 commit
  21. 31 Jan, 2015 1 commit
  22. 30 Jan, 2015 1 commit
  23. 29 Jan, 2015 1 commit
  24. 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.
      7aefdaa1
  25. 27 Jan, 2015 2 commits
    • Leigh Stoller's avatar
      Two co-mingled sets of changes: · 85cb063b
      Leigh Stoller authored
      1) Implement the latest dataset read/write access settings from frontend to
         backend. Also updates for simultaneous read-only usage.
      
      2) New configure options: PROTOGENI_LOCALUSER and PROTOGENI_GENIWEBLOGIN.
      
         The first changes the way that projects and users are treated at the
         CM. When set, we create real accounts (marked as nonlocal) for users and
         also create real projects (also marked as nonlocal). Users are added to
         those projects according to their credentials. The underlying experiment
         is thus owned by the user and in the project, although all the work is
         still done by the geniuser pseudo user. The advantage of this approach
         is that we can use standard emulab access checks to control access to
         objects like datasets. Maybe images too at some point.
      
         NOTE: Users are not removed from projects once they are added; we are
         going to need to deal with this, perhaps by adding an expiration stamp
         to the groups_membership tables, and using the credential expiration to
         mark it.
      
         The second new configure option turns on the web login via the geni
         trusted signer. So, if I create a sliver on a backend cluster when both
         options are set, I can use the trusted signer to log into my newly
         created account on the cluster, and see it (via the emulab classic web
         interface).
      
         All this is in flux, might end up being a bogus approach in the end.
      85cb063b
    • Leigh Stoller's avatar
      Add option to specify experiment creator, so that one user (say geniuser) · f869d8b7
      Leigh Stoller authored
      can create an experiment for another user.
      f869d8b7
  26. 26 Jan, 2015 2 commits
  27. 22 Jan, 2015 2 commits
  28. 17 Jan, 2015 1 commit
  29. 15 Jan, 2015 4 commits