1. 12 Oct, 2015 3 commits
  2. 09 Oct, 2015 1 commit
    • Leigh B Stoller's avatar
      Change how all geni images are imported by url; always import as geniuser · 0c653722
      Leigh B Stoller authored
      and always import into the GeniSlices project. Previously, images were
      being imported into the project of the slice experiment, by the geniuser.
      
      When PROTOGENI_LOCALUSER is turned off, this change does not affect
      anything, since it is still geniuser doing the import, and all imported
      images are consider global and thus cross-project usable. So where we stick
      the image is not really important, but putting all geni imported images in
      one place is more convenient (sure makes it easier to find them). But more
      important, this change is backwards compatible with existing imports. 
      
      Later, if the source image is updated, and a new user (in another project)
      uses that image, the update (pulling the updated image scross) is done by
      geniuser (who is the leader of all geni holding projects), who has write
      access to the image whatever project it is in. 
      
      What about when PROTOGENI_LOCALUSER is turned on? There are actually two
      sub cases here.
      
      1. The user is using an aggregate in a different domain then their SA. Say,
         when a Cloudlab Portal user is creating an experiment at the Clemson
         cluster (which has PROTOGENI_LOCALUSER=1). In this case, clemson does
         not know anything about the user anyway, and so its pretty much like the
         case described above since everything is done by the geniuser in holding
         projects owned by the geniuser.
      
      2. The user is using the same aggregate as their SA. Say, when a Cloudlab
         Portal user is creating an experiment at the Emulab cluster. In this
         case Emulab knows the user and project, and everything is done as that
         user in the actual project (there is no geni holding project).
      
         If we import the image into that project as the actual user, we are okay
         at first; as above, all images are global and cross-project, so anyone
         can use it. But what if the source image changes and then a different
         user in a different project tries to use it? The backend is going to try
         to import the new version, but that fails cause the current user does
         not have write access to the image.
      
         Hence the real reason for this change; if always import into GeniSlices
         as geniuser, we do not get into this permission problem.
      0c653722
  3. 07 Oct, 2015 1 commit
  4. 06 Oct, 2015 3 commits
  5. 05 Oct, 2015 1 commit
  6. 24 Sep, 2015 2 commits
    • Leigh B Stoller's avatar
      ee23571f
    • Leigh B Stoller's avatar
      Add AddNodes and DeleteNodes, which are convenience functions for the HPC · c3339c9d
      Leigh B Stoller authored
      folks.
      
      AddNodes($slice_urn, $credentials, $nodes):
      
      The "nodes" argument is a hash that looks like:
      
        {"node45" : {"diskimage" : "urn...",
                     "startup"   : "/bin/echo",
                     "tarballs"  : ["tarball1", "tarball2", ...],
                     "lans"      : ["lan1", "lan2", ...]
                     "node"      : "pc189"},
         "nodeXX" : {...}}
      
      DeleteNodes($slice_urn, $credentials, $nodes):
      
      The "nodes" argument is a list like:
      
        ["node45", ...]
      
      Any node can be deleted, but it is not yet clear what happens if all the
      nodes of a lan are removed. I probably need to do some work there, but
      David can start with this.
      c3339c9d
  7. 23 Sep, 2015 2 commits
  8. 22 Sep, 2015 4 commits
  9. 18 Sep, 2015 1 commit
  10. 17 Sep, 2015 3 commits
  11. 14 Sep, 2015 3 commits
  12. 10 Sep, 2015 1 commit
  13. 08 Sep, 2015 4 commits
  14. 03 Sep, 2015 2 commits
  15. 31 Aug, 2015 5 commits
  16. 26 Aug, 2015 1 commit
  17. 25 Aug, 2015 1 commit
    • Leigh B Stoller's avatar
      Add a new table image_boot_status to record boot success/failure each time · 4fa9d2ea
      Leigh B Stoller authored
      an image is loaded on a node. We want to know both success and failure over
      time so that we can determine when a image works or does not work on a
      particular node/type. This is primarily for the image tracker to determine
      what images work on what node types, but might be useful for in other
      situations. I realize this duplicates some info we already have in the
      image_history table, but that does not record failure, only success, and it
      mostly concerned with who is using what images.
      4fa9d2ea
  18. 24 Aug, 2015 2 commits