1. 17 May, 2011 1 commit
    • David Johnson's avatar
      Add per-experiment switch support. · ea496d44
      David Johnson authored
      Per-experiment switch stacks only come into being if the experiment
      actually has a switch allocated to it.  If not, tbswap and snmpit
      should function unchanged.  If there is a per-experiment stack that needs
      configuration, we first invoke normal snmpit in the normal place, but we
      use the new snmpit option `--skip-supplied' in combination with -S to skip
      the per-experiment stack.  We then configure the per-experiment stack by
      itself with -S after os_setup has completed.
      There are some new functions in the db backend stuff to create, modify,
      and remove per-experiment switches.
      There is some new code in snmpit to do the --skip-supplied filtering.  I
      also put all the -S, -i, and --skip-supplied stuff into portstats...
      because we also can't call portstats on a per-experiment switch in tbswap;
      otherwise it will hang and/or fail.
  2. 12 May, 2011 1 commit
  3. 11 Apr, 2011 1 commit
  4. 04 Apr, 2011 1 commit
    • David Johnson's avatar
      Add dynamic, per-experiment blobs. Add tables for client side service blobs. · 40039320
      David Johnson authored
      Per-experiment blobs can be created by the parser, and are inserted into
      the blobs table at swapin based on what's in virt_blobs.  We go to some
      effort to keep any existing filename<->uuid mapping in teh blobs table
      so that any caching already done by the server and client in a previous
      download of a blob remains intact.  We also remove blobs on experiment
      modify that are no longer necessary.  Finally, we remove dynamic blobs
      at swapout.
  5. 02 Feb, 2011 1 commit
  6. 07 Dec, 2010 1 commit
  7. 25 Oct, 2010 1 commit
    • Leigh B Stoller's avatar
      New module, called Emulab Features. The basic usage (see tbswap) is: · 1d430992
      Leigh B Stoller authored
      use EmulabFeatures;
      if (EmulabFeatures->FeatureEnabled("NewMapper", $user, $group, $experiment)) {
         # Do something
      else {
         # Do something else.
      where $user, $group, and $experiment is the current Emulab user, group, and
      experiment the script is operating as. Any of them can be undef. Note that
      features can easily be globally enabled or disabled (bypassing user/group
      check). See below.
      There are two scripts to deal with features. The easy one is the script to
      grant (or revoke) feature usage to a particular user or group or experiment:
      boss> wap grantfeature -u stoller NewMapper
      boss> wap grantfeature -p geni NewMapper
      boss> wap grantfeature -e geni,myexp NewMapper
      Add -r to revoke the feature.
      The other script is for managing features. To create a new feature:
      boss> wap emulabfeature create NewFeature 'A pithy description'
      which adds the feature to the emulab_features DB table. Use "delete"
      to remove a feature from the DB.
      You can globally enable and disable features for all users/groups (the
      user/group checks are bypassed). Global disable overrides global
      enable. There are actually two different flags. Lots of rope, I mean
      boss> wap emulabfeature enable NewFeature 1
      boss> wap emulabfeature enable NewFeature 0
      boss> wap emulabfeature disable NewFeature 1
      boss> wap emulabfeature disable NewFeature 0
      To display a list of all features and associated settings:
      boss> wap emulabfeature list
      To show the details (including the users and groups) of a specific
      boss> wap emulabfeature show NewFeature
      Oh, if a test is made in the code for a feature, and that feature is
      not in the emulab_features table (as might be the case on other
      Emulab's), the feature is "disabled".
  8. 23 Oct, 2010 1 commit
  9. 22 Oct, 2010 1 commit
  10. 11 Oct, 2010 3 commits
    • Leigh B Stoller's avatar
      Work on an optimization to the perl code. Maybe you have noticed, but · 92f83e48
      Leigh B Stoller authored
      starting any one of our scripts can take a second or two. That time is
      spent including and compiling 10000s of thousands of lines of perl
      code, both from our libraries and from the perl libraries.
      Mostly this is just a maintenance thing; we just never thought about
      it much and we have a lot more code these days.
      So I have done two things.
      1) I have used SelfLoader() on some of our biggest perl modules.
         SelfLoader delays compilation until code is used. This is not as
         good as AutoLoader() though, and so I did it with just a few 
         modules (the biggest ones).
      2) Mostly I reorganized things:
        a) Split libdb into an EmulabConstants module and all the rest of
           the code, which is slowly getting phased out.
        b) Move little things around to avoid including libdb or Experiment
           (the biggest files).
        c) Change "use foo" in many places to a "require foo" in the
           function that actually uses that module. This was really a big
           win cause we have dozens of cases where we would include a
           module, but use it in only one place and typically not all.
      Most things are now starting up in 1/3 the time. I am hoping this will
      help to reduce the load spiking we see on boss, and also help with the
      upcoming Geni tutorial (which kill boss last time).
    • Jonathon Duerig's avatar
      Bugfix: Fix typo to ClemsonGENI clause · 40a1c96e
      Jonathon Duerig authored
    • Jonathon Duerig's avatar
  11. 28 Sep, 2010 1 commit
  12. 20 Sep, 2010 1 commit
  13. 19 Jul, 2010 1 commit
  14. 16 Jul, 2010 1 commit
  15. 29 Jun, 2010 2 commits
  16. 25 Jun, 2010 1 commit
  17. 10 Jun, 2010 1 commit
  18. 08 Jun, 2010 1 commit
  19. 14 Apr, 2010 2 commits
    • Mike Hibler's avatar
      Changes for speeding up elabinelab server setup. · 6feda7d3
      Mike Hibler authored
      Boss/ops/fs: reboot them together after setup rather than serially.
      Nodes: leave them in PXEWAIT throughout the setup, until after boss has
      been rebooted.  At that point we send them the new bootinfo RESTART command
      telling pxeboot to re-DHCP and use the new info obtained (next-server) to
      contact a potentially new boss node.  This is a quick way to switch a node
      in PXEWAIT from talking to the outer boss to talking to the inner one.
      A significant number of rinky-dink changes were needed to do this, primarily
      adding a new state, PXELIMBO, where nodes can be sent to sit until they are
      restarted.  It turns out, just putting them in an existing state such as
      PXEWAKEUP or SHUTDOWN wouldn't work, as they tend to timeout or otherwise
    • Leigh B Stoller's avatar
      Fix syntax error. · a3182f39
      Leigh B Stoller authored
  20. 08 Apr, 2010 1 commit
  21. 19 Mar, 2010 1 commit
  22. 03 Dec, 2009 1 commit
  23. 12 Nov, 2009 1 commit
  24. 10 Nov, 2009 1 commit
  25. 24 Sep, 2009 1 commit
  26. 28 Aug, 2009 1 commit
  27. 24 Aug, 2009 1 commit
  28. 07 Aug, 2009 1 commit
  29. 27 Jul, 2009 1 commit
  30. 23 Jul, 2009 3 commits
  31. 15 Jun, 2009 1 commit
  32. 11 Jun, 2009 1 commit
  33. 23 Jan, 2009 1 commit
  34. 16 Jan, 2009 1 commit