1. 29 Oct, 2015 1 commit
  2. 20 Aug, 2014 1 commit
  3. 12 Jun, 2014 1 commit
  4. 16 Apr, 2014 1 commit
  5. 30 Jan, 2014 1 commit
  6. 29 Jan, 2014 1 commit
  7. 22 Jan, 2014 1 commit
  8. 06 Jan, 2014 1 commit
    • Mike Hibler's avatar
      Add support for lease extention (renewal). · 9a6cdeae
      Mike Hibler authored
      Add CLI for extending a lease (called extenddataset on ops). The length
      of the extension and the number of times it can be extended are controlled
      by site variables.
      9a6cdeae
  9. 03 Jan, 2014 2 commits
  10. 11 Feb, 2013 1 commit
  11. 24 Sep, 2012 1 commit
    • Eric Eide's avatar
      Replace license symbols with {{{ }}}-enclosed license blocks. · 6df609a9
      Eric Eide authored
      This commit is intended to makes the license status of Emulab and
      ProtoGENI source files more clear.  It replaces license symbols like
      "EMULAB-COPYRIGHT" and "GENIPUBLIC-COPYRIGHT" with {{{ }}}-delimited
      blocks that contain actual license statements.
      
      This change was driven by the fact that today, most people acquire and
      track Emulab and ProtoGENI sources via git.
      
      Before the Emulab source code was kept in git, the Flux Research Group
      at the University of Utah would roll distributions by making tar
      files.  As part of that process, the Flux Group would replace the
      license symbols in the source files with actual license statements.
      
      When the Flux Group moved to git, people outside of the group started
      to see the source files with the "unexpanded" symbols.  This meant
      that people acquired source files without actual license statements in
      them.  All the relevant files had Utah *copyright* statements in them,
      but without the expanded *license* statements, the licensing status of
      the source files was unclear.
      
      This commit is intended to clear up that confusion.
      
      Most Utah-copyrighted files in the Emulab source tree are distributed
      under the terms of the Affero GNU General Public License, version 3
      (AGPLv3).
      
      Most Utah-copyrighted files related to ProtoGENI are distributed under
      the terms of the GENI Public License, which is a BSD-like open-source
      license.
      
      Some Utah-copyrighted files in the Emulab source tree are distributed
      under the terms of the GNU Lesser General Public License, version 2.1
      (LGPL).
      6df609a9
  12. 02 Jun, 2011 1 commit
  13. 18 Mar, 2011 1 commit
  14. 15 Dec, 2010 1 commit
  15. 25 Jun, 2009 1 commit
  16. 28 May, 2009 1 commit
    • Kevin Atkinson's avatar
      Add "-N" option to batchexp/swapexp/endexp to suppress most email to · 649cd68c
      Kevin Atkinson authored
      testbed-ops and the user.  Important email that requires testbed-ops
      attention, such as on a recursive cleanup error, will still be sent.
      In addition mail normally sent to testbed-logs will still be sent.
      
      Also, add "noemail" option to xmlrpc server methods corresponding to
      those commands, and "-N" option to related commands in script_wrapper.
      649cd68c
  17. 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
  18. 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
  19. 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
  20. 15 May, 2007 1 commit
    • 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
  21. 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
  22. 15 Feb, 2007 1 commit
  23. 25 Jan, 2007 1 commit
  24. 22 Dec, 2006 1 commit
  25. 25 Oct, 2006 1 commit
  26. 12 Oct, 2006 1 commit
    • Leigh Stoller's avatar
      By popular demand, give user a choice of where to get the next set of · bb996961
      Leigh 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
  27. 28 Sep, 2006 1 commit
  28. 26 Sep, 2006 1 commit
  29. 20 Sep, 2006 1 commit
    • Leigh Stoller's avatar
      By popular demand, you can now force a swap modify to be done when · b9161642
      Leigh Stoller authored
      doing a Start Run. On the web page, there is a new checkbox, and
      on ops, template_startrun takes a new -m option.
      
      Caveat: You cannot specify a new NS file, yet. The original file is
      reparsed, and the idea is that a change in the template parameters
      will result in a change to the topology. I will add the ability to
      specify a new NS file in the next revision of this change.
      
      If you really really want to change the NS file, go to
      /proj/$pid/exp/$eid/archive/nsdata and edit nsfile.ns ...
      
      In addtion, DATASTORE is now defined while parsing the NS file. This
      turned to be quite the headache!
      b9161642
  30. 13 Sep, 2006 1 commit
    • Leigh Stoller's avatar
      Changes to allow waiting for a specific completion event, which is needed · 5c564bc8
      Leigh Stoller authored
      to make stoprun waiting work correctly.
      
      When tevc is invoked with the -w (wait for completion) option, tevc
      generates a token to put into the notification. The event scheduler will
      not generate a new token if there is already on in the notification, but
      instead pass it on.
      
      For the specific case of stoprun, the simulator agent has to pass that
      token along to boss and template_exprun, which generates the completion
      event (for reasons discussed in prior commit message).
      5c564bc8
  31. 12 Sep, 2006 1 commit
    • Leigh Stoller's avatar
      This started out as a simple little hack to add a StopRun "ns" event, but · cbdc4178
      Leigh Stoller authored
      it got more complicated as it progressed.
      
      The bulk of the change was changing template_exprun so that it can take a
      pid/eid as an alternative to eid/guid. This is a big convenience since its
      easy to find the template from a running experiment, and it makes it
      possible to invoke from the event scheduler, which has never heard of a
      template before (and its not something I wanted to teach it about).  Its
      also easier on users.
      
      Anyway, back to the stoprun event. You can now do this:
      
      	$ns at 100 "$ns stoprun"
      or
      	tevc -e pid/eid now ns stoprun
      
      You can add the -w option to wait for the completion event that is sent,
      but this brings me to the glaring problems with this whole thing.
      
      * First, the scheduler has to fire off the stoprun in the background,
        since if it waits, we get deadlock. Why? Cause the implementation of
        stoprun uses the event system (SNAPSHOT event, other things), and if
        the scheduler is sitting and waiting, nothing happens.
      
        Okay, the solution to this was to generate a COMPLETION event from
        template_exprun once the stop operation is complete. This brings me
        to the second problem ...
      
      * Worse, is that the "ns" events that are sent to implement stoprun (like
        snapshot) send their own completion events, and that confuses anyone
        waiting on the original stoprun event (it returns early).
      
        So what to do about this? There is a "token" field in the completion
        event structure, which I presume is to allow you to match things up.  But
        there is no way to set this token using tevc (and then wait for it), and
        besides, the event scheduler makes them up anyway and sticks them into
        the event. So, the seed of a fix are already germinating in my mind, but
        I wanted to get this commit in so that Mike would have fun reading this
        commit log.
      cbdc4178
  32. 05 Sep, 2006 1 commit
    • Leigh Stoller's avatar
      A bunch of template changes resulting from meetings last week. · 087dbfff
      Leigh Stoller authored
      * Add XMLRPC interface for template swapin,stoprun,startrun,swapout and
        add the appropriate wrappers to the script_wrapper on ops.
      
      * Allow parameter descriptions in NS files. This is probably not in its
        final form since its a bit confusing as to what has priority; something
        in the NS file or a metadata item. Anyway, you can do this in your NS
        file:
      
      	$ns define-template-parameter GUID "0/0" "The GUID to be analyzed"
      
        The rules are currently that the NS file description has priority and
        is copied to child templates, unless the user has modified a description
        via the web interface, in which case the NS file description is ignored.
        I know, sounds awful, but for the most part people are going to use the
        NS file anyway.
      
      * Add "clear" option when starting a new experiment run; the per
        experiment DB at the logholes are cleared. Note that this is *not* the
        default behaviour; you have to either check the checkbox on the web form
        or use the -c option to the script wrapper, or clear=yes if talking
        directly to the XMLRPC server.
      
      * Fix up how email is generated for template_swapin and template_create,
        so that Kevin can debug tblog/tbreport stuff, but also so that we maintain
        mail logs as before. I have made some improvements to libaudit so as to
        centralize the mail goo, and avoid duplicating all that stuff.
      
      * Minor fixes to the program agent so that the new environment strings are
        sent before the program agent exits and reloads them!
      
      * Other minor little things.
      087dbfff
  33. 31 Aug, 2006 1 commit
    • Leigh Stoller's avatar
      * Finish up the Commit From Template support. · 3327ba01
      Leigh Stoller authored
      * Export the above via the XMLRPC interface and add a wrapper function
        to the script_wrapper. This allows you do to this on ops:
      
      	cd /proj/testbed/templates/10023/1
              Edit some files
              template_commit
      
        Which creates a new template, using the current directory to infer
        the template. Otherwise, provide the template GUID on the command line.
        Hmm, maybe this should be called template_modify? Either way, the
        name does not quite match
      
      * Export template_export via the XMLRPC wrapper. This allows you to
        export a template (instance) record from the command line on ops.
      
      
      	cd /proj/testbed/templates/10023/1
              template_export -i 12
              Exported to /proj/testbed/export/10000/3/12
      
        Which exports the template record for instance number 12. Again, the
        GUID is infered, but you can specify one on the command line. The export
        directory is printed so you know where it went. Note that export does
        *not* populate a DB on ops with the old DB data.
      3327ba01
  34. 23 Apr, 2006 1 commit
  35. 16 Feb, 2006 1 commit
  36. 30 Aug, 2005 1 commit
  37. 24 Jun, 2005 1 commit
  38. 22 Mar, 2005 1 commit
  39. 10 Dec, 2004 1 commit