1. 01 Oct, 2008 1 commit
  2. 15 Aug, 2008 1 commit
  3. 18 Jul, 2008 1 commit
  4. 01 Jul, 2008 1 commit
  5. 26 Jun, 2008 1 commit
  6. 06 Mar, 2008 1 commit
  7. 11 Feb, 2008 1 commit
  8. 16 Nov, 2007 1 commit
  9. 08 Oct, 2007 1 commit
  10. 25 Sep, 2007 1 commit
  11. 24 Sep, 2007 2 commits
  12. 21 Sep, 2007 1 commit
  13. 10 Sep, 2007 1 commit
  14. 07 Sep, 2007 3 commits
  15. 18 Jul, 2007 1 commit
  16. 09 Jul, 2007 1 commit
    • Leigh Stoller's avatar
      Checkpoint my cvs interface to the workbench. This first cut uses the · 8371fc79
      Leigh 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
  17. 31 May, 2007 2 commits
  18. 30 May, 2007 1 commit
  19. 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
  20. 28 May, 2007 1 commit
    • Leigh Stoller's avatar
      Implement two requests by Eric: · e12ea1e2
      Leigh 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
  21. 24 May, 2007 1 commit
  22. 23 May, 2007 1 commit
    • Leigh Stoller's avatar
      First cut at template checkout and commit from a checkout. The interface · b674bc7b
      Leigh 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
  23. 21 May, 2007 1 commit
  24. 15 May, 2007 2 commits
    • Leigh Stoller's avatar
      Ug, fix syntax error in previous revision. · dbf1fe73
      Leigh Stoller authored
      dbf1fe73
    • Leigh Stoller's avatar
      Checkpoint changes that have been discussed in the last few weeks: · c4f53202
      Leigh 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
  25. 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
  26. 26 Apr, 2007 1 commit
  27. 25 Apr, 2007 1 commit
  28. 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
  29. 25 Mar, 2007 1 commit
  30. 23 Mar, 2007 1 commit
  31. 06 Mar, 2007 1 commit
  32. 15 Feb, 2007 1 commit
  33. 13 Feb, 2007 1 commit
  34. 26 Jan, 2007 1 commit
  35. 25 Jan, 2007 1 commit