1. 24 Feb, 2010 1 commit
  2. 12 Feb, 2010 4 commits
  3. 11 Feb, 2010 4 commits
  4. 09 Feb, 2010 2 commits
  5. 04 Feb, 2010 3 commits
  6. 03 Feb, 2010 2 commits
  7. 26 Jan, 2010 1 commit
  8. 20 Jan, 2010 1 commit
  9. 15 Jan, 2010 2 commits
  10. 07 Jan, 2010 1 commit
  11. 06 Jan, 2010 2 commits
    • Leigh B. Stoller's avatar
      Run xmllint over the rspec in GetTicket. Return the XML errors. · 7046b6c3
      Leigh B. Stoller authored
      Change all the test scripts to print the errors.
      7046b6c3
    • Leigh B. Stoller's avatar
      Slice expiration changes. The crux of these changes: · 5c63cf86
      Leigh B. Stoller authored
      1. You cannot unregister a slice at the SA before it has expired. This
         will be annoying at times, but the alphanumeric namespace for slice
         ames is probably big enough for us.
      
      2. To renew a slice, the easiest approach is to call the Renew method
         at the SA, get a new credential for the slice, and then pass that
         to renew on the CMs where you have slivers.
      
      The changes address the problem of slice expiration.  Before this
      change, when registering a slice at the Slice Authority, there was no
      way to give it an expiration time. The SA just assigns a default
      (currently one hour). Then when asking for a ticket at a CM, you can
      specify a "valid_until" field in the rspec, which becomes the sliver
      expiration time at that CM. You can later (before it expires) "renew"
      the sliver, extending the time. Both the sliver and the slice will
      expire from the CM at that time.
      
      Further complicating things is that credentials also have an
      expiration time in them so that credentials are not valid forever. A
      slice credential picks up the expiration time that the SA assigned to
      the slice (mentioned in the first paragraph).
      
      A problem is that this arrangement allows you to extend the expiration
      of a sliver past the expiration of the slice that is recorded at the
      SA. This makes it impossible to expire slice records at the SA since
      if we did, and there were outstanding slivers, you could get into a
      situation where you would have no ability to access those slivers. (an
      admin person can always kill off the sliver).
      
      Remember, the SA cannot know for sure if there are any slivers out
      there, especially if they can exist past the expiration of the slice.
      
      The solution:
      
      * Provide a Renew call at the SA to update the slice expiration time.
        Also allow for an expiration time in the Register() call.
      
        The SA will need to abide by these three rules:
        1. Never issue slice credentials which expire later than the
           corresponding slice
        2. Never allow the slice expiration time to be moved earlier
        3. Never deregister slices before they expire [*].
      
      * Change the CM to not set the expiration of a sliver past the
        expiration of the slice credential; the credential expiration is an
        upper bound on the valid_until field of the rspec. Instead, one must
        first extend the slice at the SA, get a new slice credential, and
        use that to extend the sliver at the CM.
      
      * For consistency with the SA, the CM API will changed so that
        RenewSliver() becomes RenewSlice(), and it will require the
        slice credential.
      5c63cf86
  12. 18 Dec, 2009 1 commit
    • Leigh B. Stoller's avatar
      Changes to support the SPP nodes. My approach was a little odd. · fd015646
      Leigh B. Stoller authored
      What I did was create node table entries for the three SPP nodes.
      These are designated as local, shared nodes, reserved to a holding
      experiment. This allowed me to use all of the existing shared node
      pool support, albeit with a couple of tweaks in libvtop that I will
      not bother to mention since they are hideous (another thing I need to
      fix).
      
      The virtual nodes that are created on the spp nodes are figments; they
      will never be setup, booted or torn down. They exist simply as place
      holders in the DB, in order hold the reserved bandwidth on the network
      interfaces. In other words, you can create as many of these imaginary
      spp nodes (in different slices if you like) as there are interfaces on
      the spp node. Or you can create a single spp imaginary node with all
      of the interfaces. You get the idea; its the reserved bandwidth that
      drives the allocation.
      
      There are also some minor spp specific changes in vnode_setup.in to
      avoid trying to generalize things. I will return to this later as
      needed.
      
      See this wiki page for info and sample rspecs:
      
      https://www.protogeni.net/trac/protogeni/wiki/SPPNodes
      fd015646
  13. 11 Dec, 2009 1 commit
  14. 07 Dec, 2009 1 commit
    • Leigh B. Stoller's avatar
      No longer use the ssh keys in the Emulab database when the protogeni · d60b9acd
      Leigh B. Stoller authored
      user is a local user. Instead, all users have to send along their keys
      in the RedeemTicket() call, and those keys land in the new Emulab
      table called nonlocal_user_pubkeys, and tmcd will use that table when
      sending keys over local nodes.
      
      This change removes the inconsistency in key handling between slivers
      created locally and slivers created at a foreign CM.
      d60b9acd
  15. 04 Dec, 2009 1 commit
  16. 03 Dec, 2009 1 commit
  17. 02 Dec, 2009 1 commit
    • Leigh B. Stoller's avatar
      Checkpoint. · f83ba977
      Leigh B. Stoller authored
      * More URN issues dealt with.
      
      * Sliver registration and unregistraton (CM to SA).
      
      * More V2 status stuff.
      
      * Other fixes.
      f83ba977
  18. 13 Nov, 2009 2 commits
  19. 06 Nov, 2009 2 commits
  20. 03 Nov, 2009 2 commits
  21. 02 Nov, 2009 2 commits
  22. 29 Oct, 2009 2 commits
  23. 26 Oct, 2009 1 commit
    • Leigh B. Stoller's avatar
      Fill in the "minimal" part of the version two CM API, now functional. · 990de36f
      Leigh B. Stoller authored
      * Most of the changes in GeniCM are simple reorganizations to allow me
        to call into the code from the GeniCMV2 module. This is to avoid
        code duplication as much as possible. Eventually, I will have to
        duplicate the code, but for the moment this works okay.
      
      * I am ignoring the slice_urn argument for now. Will add that later.
      
      * See protogeni/test/version2 for the version two test cases.
      990de36f