1. 15 Mar, 2015 1 commit
  2. 13 Mar, 2015 1 commit
  3. 09 Mar, 2015 1 commit
  4. 05 Mar, 2015 2 commits
  5. 20 Feb, 2015 1 commit
  6. 12 Feb, 2015 1 commit
  7. 09 Feb, 2015 1 commit
  8. 04 Feb, 2015 2 commits
  9. 03 Feb, 2015 1 commit
  10. 02 Feb, 2015 1 commit
  11. 31 Jan, 2015 1 commit
  12. 30 Jan, 2015 1 commit
  13. 29 Jan, 2015 1 commit
  14. 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.
  15. 27 Jan, 2015 2 commits
    • Leigh B Stoller's avatar
      Two co-mingled sets of changes: · 85cb063b
      Leigh B Stoller authored
      1) Implement the latest dataset read/write access settings from frontend to
         backend. Also updates for simultaneous read-only usage.
         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
         All this is in flux, might end up being a bogus approach in the end.
    • Leigh B Stoller's avatar
      Add option to specify experiment creator, so that one user (say geniuser) · f869d8b7
      Leigh B Stoller authored
      can create an experiment for another user.
  16. 26 Jan, 2015 2 commits
  17. 22 Jan, 2015 2 commits
  18. 17 Jan, 2015 1 commit
  19. 15 Jan, 2015 6 commits
  20. 13 Jan, 2015 2 commits
  21. 12 Jan, 2015 5 commits
  22. 09 Jan, 2015 1 commit
  23. 08 Jan, 2015 3 commits