1. 06 Mar, 2008 1 commit
  2. 11 Feb, 2008 1 commit
  3. 16 Nov, 2007 1 commit
  4. 08 Oct, 2007 1 commit
  5. 25 Sep, 2007 1 commit
  6. 24 Sep, 2007 2 commits
  7. 21 Sep, 2007 1 commit
  8. 10 Sep, 2007 1 commit
  9. 07 Sep, 2007 3 commits
  10. 18 Jul, 2007 1 commit
  11. 09 Jul, 2007 1 commit
    • Leigh B. Stoller's avatar
      Checkpoint my cvs interface to the workbench. This first cut uses the · 8371fc79
      Leigh B. Stoller authored
      "rtag" directive to initiate template modify operations. So, to get started
      you do a checkout:
      
        cvs -d ops.emulab.net:/proj/$pid/templates/XXXXX/cvsrepo checkout XXXXX
      
      where XXXXX is the part of the guid (10000/1) before the slash. Might try
      and roll all templates into a single project wide repo at some point, to
      avoid the extraneous path stuff, but didn't want to worry that just yet.
      
      Okay, so have a checkout. You can work along the trunk, doing commits. To
      create a new template (a modify of the existing template), you tag the tree
      using rtag:
      
        cvs -d ops.emulab.net:/proj/$pid/templates/XXXXX/cvsrepo rtag mytag XXXXX
      
      A template modify is started at the end, and you should probably wait for
      email before continuing. Eventually I will need to add locking of some
      kind, but I have to do the modify in the background, or else I get deadlock
      cause cvs keeps the repo locked, and the modify also needs to access it.
      
      Each time you tag along the trunk, you get a modified template, which in
      the history diagram looks like:
      
        10000/1 --> 10000/2 --> 10000/3 ...
      
      If you want to branch, say at 10000/2 you can create a branch tag using rtag:
      
        cvs -d [cut] rtag -r T10000/2 -b mytag2 XXXXX
      
      You can also use your own tags for -r option, but I also create a TXXXXX/YY
      tag at each template modify, which is easy to remember.
      
      Then update your sandbox to the new branch, commit changes along that
      branch, and then later use rtag again to initiate a template modify
      operation:
      
        cvs update -r mytag2
        cvs commit ...
        cvs -d [cut] rtag -r mytag2 mytag3 XXXXX
      
      And now the history diagram looks like:
      
        10000/1 --> 10000/2 --> 10000/3 ...
                      |
                      |
                      -> 10000/4 ...
      
      You should be able to mix interaction via the web with interaction via the
      cvs interface. I've tested it, although not extensively.
      8371fc79
  12. 31 May, 2007 2 commits
  13. 30 May, 2007 1 commit
  14. 29 May, 2007 1 commit
    • David Johnson's avatar
      Add a little class with a couple SimpleXMLRPCServer class extensions. The · 8aecc4fc
      David Johnson authored
      first one makes python's basic xmlrpc facility act a bit like java RMI
      (the SimpleObjectXMLRPCServer).  The second (InetACLXMLRPCServer) filters
      incoming requests based on allowed networks (i.e., 155.98.32.0/20 or
      similar).  If ever desired, they should be compatible with the boss xmlrpc
      server model) with just a tiny hack.
      8aecc4fc
  15. 28 May, 2007 1 commit
    • Leigh B. Stoller's avatar
      Implement two requests by Eric: · e12ea1e2
      Leigh B. Stoller authored
      * The checkout directory now includes just the datastore directory and
        tbdata/nsfile.ns. This removes a bunch of clutter.
      
      * You can now run template_commit in any subdir of a checkout; the
        python wrapper will crawl upwards looking for the .template file.
      
        Note that I removed the option that allowed you to do a commit from
        the template tree in /proj/pid/templates since that directory will
        ultimately go away (or at least hide from view), and cause it
        conflicted with the new option and I didn't want to make things any
        messier for no reason.
      e12ea1e2
  16. 24 May, 2007 1 commit
  17. 23 May, 2007 1 commit
    • Leigh B. Stoller's avatar
      First cut at template checkout and commit from a checkout. The interface · b674bc7b
      Leigh B. Stoller authored
      described is the one exported to ops via the XMLRPC interface. This is
      just playing aroundl no doubt this stuff is going to change.
      
      * template_checkout guid/vers
      
        Checkout a copy of the template to the current working directory.
      
      * template_commit
      
        Modify the previous template checkout, using the nsfile contained in
        the tbdata directory (subdir of the current directory). In other words,
        the current template is modified, creating a new template in the
        current working directory (the current directory refers to the new
        template).
      
        The datastore subdir is imported into the new template, but that is
        the only directory that is imported at present. Might change that.
      
      So this sounds much cooler then it really is. Why?
      
      * This only works from ops.
      
      * The "current directory" must be one of the standard approved directories
        (/proj, /users, /groups).
      
      * Cause, boss reads and writes that directory via NFS, as told to it
        by the xmlrpc client.
      
      At some point in the future it would be nice to support something
      fancier, using a custom transport, but lets see how this goes.
      b674bc7b
  18. 21 May, 2007 1 commit
  19. 15 May, 2007 2 commits
    • Leigh B. Stoller's avatar
      dbf1fe73
    • Leigh B. Stoller's avatar
      Checkpoint changes that have been discussed in the last few weeks: · c4f53202
      Leigh B. Stoller authored
      * Records are now "help open" when a run is stopped. When the next run
        is started, a check is made to see if the files
        (/project/$pid/exp/$eid) have changed, and if so a new version of the
        archive is committed before the next run is started.
      
      * Change the way swapmod is handled within an instance. A new option
        on the ShowExp page called Modify Resources. The intent is to allow
        an instance to be modified without having to start and stop runs,
        which tends to clutter things up, according to our user base. So, if
        you are within a run, that run is reset (reused) after the swapmod is
        finished. You can do this as many times as you like. If you are
        between runs (last operation was a stoprun), do the swapmod and then
        "speculatively" start a new run. Subsequent modifies reuse the that
        run again, as above.
      
        I think this is what Kevin was after ... there are some UI issues
        that may need to be resolved, will wait to hear what people have to
        say.
      
      * Revising a record is now supported. Export, change in place, and
        then use the Revise link on the ShowRun page. Currently this has to
        happen from the export directory on ops, but eventually allow an
        upload (to correspond to downloaded exports)
      
      * Check to see if export already exists, and give warning. Added a
        checkbox that allows user to overwrite the export.
      
      * A bunch of minor UI changes to the various template pages.
      c4f53202
  20. 03 May, 2007 1 commit
    • Kevin Atkinson's avatar
      · 6353beca
      Kevin Atkinson authored
      Add template_startrun to list of symbolic links to create and update
      help screen for template_startrun.
      6353beca
  21. 26 Apr, 2007 1 commit
  22. 25 Apr, 2007 1 commit
  23. 30 Mar, 2007 1 commit
    • Robert Ricci's avatar
      Patch from Keith Slower @ Berkeley: · 92bb918a
      Robert Ricci authored
      "I implemented and tested extensions to snmpit & friends so that an
      elabinelab could additional request that an experimental interface be
      placed in trunked mode, to discover the vlan tags associated with
      vlans, and to request modifications to existing vlans belonging to an
      elabinelab without tearing it down and reconstructing it."
      92bb918a
  24. 25 Mar, 2007 1 commit
  25. 23 Mar, 2007 1 commit
  26. 06 Mar, 2007 1 commit
  27. 15 Feb, 2007 1 commit
  28. 13 Feb, 2007 1 commit
  29. 26 Jan, 2007 1 commit
  30. 25 Jan, 2007 1 commit
  31. 22 Dec, 2006 1 commit
  32. 01 Dec, 2006 1 commit
  33. 25 Oct, 2006 1 commit
  34. 20 Oct, 2006 1 commit
    • Mike Hibler's avatar
      Wow, this should make me look important! · afa5e919
      Mike Hibler authored
      Two-day boondoggle to support "/scratch", an optional large, shared filesystem
      for users.  To do this, I needed to find all the instances where /proj is used
      and behave accordingly.  The boondoggle part was the decision to gather up all
      the hardwired instances of shared directory names ("/proj", "/users", etc.)
      so that they are set in a common place (via unexposed configure variables).
      This is a boondoggle because:
      
      1. I didn't change the client-side scripts.  They need a different mechanism
         (e.g., tmcd) to get the info, configure is the wrong way.
      
      2. Even if I had done #1 it is likely--no, certain--that something would
         fail if you tried to rename "/proj" to be "/mike".  These names are just
         too ingrained.
      
      3. We may not even use "/scratch" as it turns out.
      
      Note, I also didn't fix any of the .html documentation.  Anyway, it is done.
      To maintain my illusion in the future you should:
      
      1. Have perl scripts include "use libtestbed" and use the defined PROJROOT(),
         et.al. functions where possible.  If not possible, make sure they run
         through configure and use @PROJROOT_DIR@, etc.
      
      2. Use the configure method for python, C, php and other languages.
      
      3. There are perl (TBValidUserDir) and php (VALIDUSERPATH) functions which
         you should call to determine if an NS, template parameter, tarball or
         other file are in "an acceptable location."  Use these functions where
         possible.  They know about the optional "scratch" filesystem.  Note that
         the perl function is over-engineered to handles cases that don't occur
         in nature.
      afa5e919
  35. 12 Oct, 2006 1 commit
    • Leigh B. Stoller's avatar
      By popular demand, give user a choice of where to get the next set of · bb996961
      Leigh B. Stoller authored
      (initial) parameters for a new run. Three choices right now; from the
      template itself, from the instance, or from the previous run. On the
      web interface this is presented as three buttons. On ops, it is the
      the -y option, which takes one of template,instance,lastrun as its
      argument (you can of course combine the -y option with an XML file to
      override specific params).
      
      At present, there is no default. Lets give it a chance to sink in
      before I pick something that will annoy 50% of the people 75% of the
      time.
      bb996961