1. 17 Oct, 2015 1 commit
    • Robert Ricci's avatar
      CORS headers to allow stats to be embedded in any domain · 557f72da
      Robert Ricci authored
      Part of the reason this is needed is that https:// and http:// are
      different origins, and CloudLab always needs to fetch this through
      https:// . But also for my own convenience in being able to stick my
      development page anywhere.
      557f72da
  2. 16 Oct, 2015 8 commits
  3. 15 Oct, 2015 13 commits
  4. 14 Oct, 2015 2 commits
  5. 13 Oct, 2015 4 commits
  6. 12 Oct, 2015 8 commits
  7. 09 Oct, 2015 4 commits
    • Leigh Stoller's avatar
      1fdf5323
    • Leigh Stoller's avatar
      Lets record who updated the image when it is copied back to the · 0c638b51
      Leigh Stoller authored
      origin cluster; this change just added the slot we need in the DB.
      0c638b51
    • Leigh Stoller's avatar
      Change how all geni images are imported by url; always import as geniuser · 0c653722
      Leigh 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
    • Leigh Stoller's avatar
      Some cleanup wrt -p importpid argument. · ae6fb72e
      Leigh Stoller authored
      ae6fb72e