1. 21 Apr, 2008 1 commit
  2. 18 Apr, 2008 2 commits
  3. 17 Apr, 2008 3 commits
  4. 13 Apr, 2008 1 commit
  5. 12 Apr, 2008 3 commits
  6. 07 Apr, 2008 1 commit
  7. 28 Mar, 2008 3 commits
    • David Johnson's avatar
      Fixes. · 77878683
      David Johnson authored
      77878683
    • David Johnson's avatar
      Add support to synch with and store plab nodegroups in our DB (plab uses · d0f1cec3
      David Johnson authored
      them to key many different control actions, and we can't ignore them
      anymore).  The driving need in this case is to dist out rootballs based on
      the nodegroup so we can test plab4.2... but other ways to use this will
      likely arise.
      
      Also expanded the notion of config attributes I added during the push to
      support multiple PLCs.  Now, config attributes are just per-PLC or
      per-slice; they are per-PLC, but also conditional across
      slice,nodegroup,node tuples.  This gives a ton of flexibility for the
      different actions we need to take based on what kind of node the node is
      -- and plab typically seems to distinguish this based on nodegroups.
      d0f1cec3
    • David Johnson's avatar
      81a10581
  8. 26 Mar, 2008 1 commit
  9. 23 Mar, 2008 1 commit
  10. 21 Feb, 2008 1 commit
  11. 14 Feb, 2008 1 commit
  12. 06 Feb, 2008 2 commits
    • David Johnson's avatar
      Forgot this. · bf22ebcb
      David Johnson authored
      bf22ebcb
    • David Johnson's avatar
      Add support for including nodes from multiple PLCs in experiments. Right · c44c47c9
      David Johnson authored
      now, this is keyed off nodetype.  Lots of hardcoded constants and config
      stuff moved to attributes in the db.  You can now set per-PLC and
      per-slice attributes, so you can (for instance) use different auth info
      whenever you want.  Experiments can use preexisting slices if somebody
      sets up the db before swapin.  Also, we no longer have to rely on
      slices.xml to sync up nodes/sites with PLC... can use xmlrpc instead.
      
      Lots of code cleanup, improved some abstractions, etc.
      c44c47c9
  13. 08 Nov, 2007 1 commit
  14. 21 Sep, 2007 1 commit
  15. 07 Sep, 2007 2 commits
  16. 05 Sep, 2007 2 commits
  17. 31 Aug, 2007 1 commit
  18. 02 Aug, 2007 1 commit
  19. 19 Jul, 2007 1 commit
  20. 16 Jul, 2007 2 commits
    • David Johnson's avatar
      Support for accessing the v4 NM via a nm-controller slice account. Now, · 88e61ae3
      David Johnson authored
      for each delegated slice we create, we set the 'delegations' attribute to
      'utah_nmcontrol', the name of our nm-controller slice that has permissions
      to talk to the NM.
      
      Also, a few other fixes.
      88e61ae3
    • David Johnson's avatar
      Several things in this commit: · 3bbd843b
      David Johnson authored
        * Prior to this commit, libplab depended on db state to create slivers
          and slices.  Now it can be done using the regular command line tools
          without the metadata in the db.  This makes development and debugging
          much easier and allows us to use the command-line tools even if state has
          been cleared out of the db (i.e., for sliver garbage collection).
        * Add support for sliver start/stop/restart via the v4 NM.
        * Some support for sliver garbage collection.
        * Various other improvements and cleanup.
      3bbd843b
  21. 20 Jun, 2007 1 commit
    • Leigh B. Stoller's avatar
      Add summary node utilization stats. The initial values are derived by · 21890006
      Leigh B. Stoller authored
      processing the node_history table, but that is *way* too slow to do on
      the fly (say, from the web interface) cause of the number of records,
      so the summary info is stored in the new node_utilization table. I
      generate the summary info as new entries are added to node_history (in
      SetNodeHistory) but if that becomes too messy, we can just as easily
      shift to processing the table on a nightly basis.
      
      Note that I added a new "inception" date field to the nodes table,
      which will get set on new nodes, but for existing nodes I have to
      derive it from the first entry in the node_history table, or else the
      numbers will not make sense.
      21890006
  22. 06 Jun, 2007 1 commit
  23. 15 May, 2007 2 commits
  24. 03 May, 2007 2 commits
  25. 25 Apr, 2007 3 commits