1. 28 Mar, 2005 2 commits
  2. 25 Mar, 2005 2 commits
  3. 24 Mar, 2005 1 commit
  4. 22 Mar, 2005 3 commits
  5. 20 Mar, 2005 1 commit
  6. 18 Mar, 2005 1 commit
  7. 17 Mar, 2005 2 commits
    • Mike Hibler's avatar
      Yeah, I'm a dork. · 9de8411a
      Mike Hibler authored
      Put back the changes I removed in my last commit.
      You would think I would know how to read diff output by now...
      9de8411a
    • Mike Hibler's avatar
      Partial support for disk-zeroing on experiment termination. · 60e7adb8
      Mike Hibler authored
      I did the "back half" support.  If the 'mustwipe' field is non-zero
      in the reserved table entry for a node then its disk must be zeroed.
      How the zeroing is done, depends on the value of the mustwipe field.
      Right now, '1' means pass the '-z' option to frisbee to have it zero
      all non-allocated blocks.  The value '2' is reserved for enabling a
      "full wipe" pass of the disk before running frisbee, which Keith Sklower
      (DETER) wanted to be able to do.  Note that 1 and 2 are effectively the
      same, if we are loading a full-disk image; i.e. all non-allocated blocks
      from the new image are zeroed.  But if the disk were being loaded with
      a single-partition image, then "frisbee -z" would only wipe unused
      blocks in that partition.
      
      The reload_daemon has been modified to extract the mustwipe info and
      invoke os_load accordingly.   os_load now takes a "-z <type>" option
      to enable the zeroing by setting a value in the current_reloads table.
      tmcd will read and return that info to its caller in the "loadinfo" command.
      Finally, the rc.frisbee script that runs in the frisbee MFS extracts the
      loadinfo info and crafts the frisbee startup command.
      
      What still needs to be done is the "front end," how the user specifies
      the value and how it winds up in the DB reserved table.  This will probably
      involve addition of state to the experiments table as this will likely be
      a per-experiment setting.
      60e7adb8
  8. 15 Mar, 2005 1 commit
  9. 11 Mar, 2005 1 commit
  10. 08 Mar, 2005 1 commit
  11. 07 Mar, 2005 1 commit
  12. 02 Mar, 2005 1 commit
  13. 01 Mar, 2005 1 commit
  14. 22 Feb, 2005 2 commits
    • Leigh B. Stoller's avatar
      Add loc_z to the location info table, and display that on both the · 67ff3af6
      Leigh B. Stoller authored
      static robot map and in the robot tracker applet.
      67ff3af6
    • Leigh B. Stoller's avatar
      Okay, first attempt to deal with os_setup waittimes on a per node_type · facc7acd
      Leigh B. Stoller authored
      and per OSID basis.
      
      * Added bios_waittime to node_types table and reboot_waittime to
        os_info table. Initialized them as follows:
      
              update node_types set bios_waittime=60 where class='pc';
              update os_info set reboot_waittime=150 where OS='Linux' or
      	  OS='FreeBSD' or OS='NetBSD';
              update os_info set reboot_waittime=180 where OS=Windows';
      
      * The bios waittime can be edited via the web interface.
      
      * The reboot waittime can be set only by admin people right now; this
        is another case of something that maybe the user should not see
        cause its too much stuff? Instead, default values are established in
        www/osiddefs.php3.
      
      * os_setup computes its per-node waitime as:
      
      	(bios_waittime + reboot_waittime) * 2
      
        as per Mike's suggestion. If either value is not defined in the DB,
        it defaults the original 7 minute value.
      facc7acd
  15. 15 Feb, 2005 1 commit
  16. 14 Feb, 2005 1 commit
  17. 08 Feb, 2005 4 commits
  18. 04 Feb, 2005 1 commit
  19. 02 Feb, 2005 1 commit
    • Leigh B. Stoller's avatar
      Add tb-set-delay-capacity NS directive: · 21044084
      Leigh B. Stoller authored
      	tb-set-delay-capacity 1
      
      Will override the default delay capacity as specfied in the node_types
      table for each node type, and set it for all types when generating the
      ptop file.
      
      This is a big stick, to be used with caution, as it will effectively
      double the number of nodes used for delay nodes (withing an experiment).
      21044084
  20. 28 Jan, 2005 4 commits
  21. 27 Jan, 2005 1 commit
  22. 26 Jan, 2005 1 commit
    • Leigh B. Stoller's avatar
      The Robot Lab Monitor Daemon. A very silly script that looks at some · 4963660a
      Leigh B. Stoller authored
      sitevars to determine if the Robot Lab is open or closed. The sitevars:
      
      * 'robotlab/override' - Override other settings and forcibly turn the lab
        "on" or "off" (open or close). When the lab is turned off, new
        experiments cannot swap in and the current experiment is immediately
        swapped out.
      
      * 'robotlab/exclusive' - The robot lab is exclusive use. Best to not mess
        with this sitevar :-)
      
      * 'robotlab/opentime' - The time that the robot lab opens in the
        morning. The default is 07:00, but feel free to change this as you like.
      
      * 'robotlab/closetime' - The time that the robot lab closes in the
        evening. The default is 18:00, but feel free to change this as you like.
      
      * 'robotlab/open' - The robot lab is open or closed. DO NOT MESS WITH THIS!
        It is updated by the robomonitord script and intended to be used by
        admission control (not done yet).
      
      The robomonitord script runs and periodically (every 2 minutes) wakes up
      and looks at the various sitevars above. The lab is open during the day,
      Monday through Friday, and closed on weekends. It is also supposed to be
      closed on holidays, but I have not added that yet.
      
      15 minutes before the lab is to be closed, a warning message is sent to the
      swapper of the experiment running on the robot testbed, that their
      experiment is going to be swapped soon. When the Robot lab is closed
      (either cause the close time was reached, or because the lab was forcibly
      closed with the override), the current experiment is immediately swapped
      out.
      
      I know, this is hopelessly bogus, but it will do until we feel like adding
      a "Lab" datatype to the system.
      4963660a
  23. 24 Jan, 2005 1 commit
    • Leigh B. Stoller's avatar
      Bottom line on this commit: Do not update the nodetypeXpid_permissions · 775ca147
      Leigh B. Stoller authored
      table by hand anymore! Update the group_policies table and then run
      the script to update the permissions table (sbin/update_permissions).
      
      Details:
      
      My original thought when I started this was that I would be able to
      replace the existing nodetypeXpid_permissions table with this new
      stuff. Well, it turns out that this was not a good thing to do, for a
      couple of reasons:
      
        * Engineering: We access the nodetypeXpid_permissions table from three
          different languages, and no way I wanted to rewrite this library in
          in python and php!
      
        * Performance: We access the nodetypeXpid_permissions from the web
          interface, on every single page load. In fact, we access it twice if
          if you count the FreePCs() count that we put at the top of the menu.
          Going through this library on each page load would be a serious drag.
      
      So, rather then actually get rid of the nodetypeXpid_permissions table, I
      decided to keep it as a "cache" of permissions stored in the group
      policies table. Each time you update the policy tables, we need to run
      the update_permissions script which will call into this library (see the
      TBUpdateNodeTypeXpidPermissions() routine) to reconstruct the permissions
      table. I have whacked the grantnodetype script to do exactly that.
      
      Note that we could proably do the same thing for users by creating an
      equivalent nodetypeXuid_permissions table, mapping users to types they
      are allowed to use. That would be a lot rows, but the amount of data in
      the table is small. That would give us very fine grained control of what
      we show people in the web interface. Not sure it is worth it though.
      
      I also added some instructions to previous commit in database-migrate.txt
      on populating the new group_policies table from the existing
      permissions table.
      775ca147
  24. 22 Jan, 2005 1 commit
  25. 18 Jan, 2005 1 commit
    • Leigh B. Stoller's avatar
      Here is a checkpoint of the admission control stuff I have been working on. · 54f55585
      Leigh B. Stoller authored
      The last part is the stuff to hook it in from assign_wrapper, and some
      additional support in assign that Rob is adding for me. This comment is
      from the top of new file db/libadminctrl.pm.in and describes everything in
      detail.
      
      # Admission control policies. These are the ones I could think of, although
      # not all of these are implemented.
      #
      #  * Number of experiments per type/class (only one expt using robots).
      #
      #  * Number of experiments per project
      #  * Number of experiments per subgroup
      #  * Number of experiments per user
      #
      #  * Number of nodes per project      (nodes really means pc testnodes)
      #  * Number of nodes per subgroup
      #  * Number of nodes per user
      #
      #  * Number of nodes of a class per project
      #  * Number of nodes of a class per group
      #  * Number of nodes of a class per user
      #
      #  * Number of nodes of a type per project
      #  * Number of nodes of a type per group
      #  * Number of nodes of a type per user
      #
      #  * Number of nodes with attribute(s) per project
      #  * Number of nodes with attribute(s) per group
      #  * Number of nodes with attribute(s) per user
      #
      # So we have group (pid/gid) policies and user policies. These are stored
      # into two different tables, group_policies and user_policies, indexed in
      # the obvious manner. Each row of the table defines a count (experiments,
      # nodes, etc) and a type of thing being counted (experiments, nodes, types,
      # classes, etc). When we test for admission, we look for each matching row
      # and test each condition. All conditions must pass. No conditions means a
      # pass. There is also some "auxdata" which holds extra information needed
      # for the policy (say, the type of node being restricted).
      #
      #      uid:     a uid
      #   policy:     'experiments', 'nodes', 'type', 'class', 'attribute'
      #    count:     a number
      #  auxdata:     a string (optional)
      #
      # Example: A user policy of ('mike', 'nodes', 10) says that poor mike is
      # not allowed to have more 10 nodes at a time, while ('mike', 'type',
      # '10', 'pc850') says that mike cannot allocate more than 10 pc850s.
      #
      # The group_policies table:
      #
      #      pid:     a pid
      #      gid:     a gid
      #   policy:     'experiments', 'nodes', 'type', 'class', 'attribute'
      #    count:     a number
      #  auxdata:     a string (optional)
      #
      # Example: A project policy of ('testbed', 'testbed', 'experiments', 10)
      # says that the testbed project may not have more then 10 experiments
      # swapped in at a time, while ('testbed', 'TG1', 'nodes', 10) says that the
      # TG1 subgroup of the testbed project may not use more than 10 nodes at
      # time.
      #
      # In addition to group and user policies (which are policies that apply to
      # specific users/projects/subgroups), we also need policies that apply to
      # all users/projects/subgroups (ie: do not want to specify a particular
      # restriction for every user!). To indicate such a policy, we use a special
      # tag in the tables (for the user or pid/gid):
      #
      #      '+'  -  The policy applies to all users (or project/groups).
      #
      # Example: ('+','experiments',10) says that no user may have more then 10
      # experiments swapped in at a time. The rule overrides anything more
      # specific (say a particular user is restricted to 20 experiments; the above
      # rule overrides that and the user (all users) is restricted to 10.
      #
      # Sometimes, you want one of these special rules to apply to everyone, but
      # *allow* it to be overridden by a more specific rule. For that we use:
      #
      #      '-'  -  The policy applies to all users (or project/groups),
      #              but can be overridden by a more specific rule.
      #
      # Example: The rules:
      #
      #	('-','type',0, 'garcia')
      #       ('testbed', 'testbed', 'type', 10, 'garcia')
      #
      # says that no one is allowed to allocate garcias, unless there is specific
      # rule that allows it; in this case the testbed project can allocate them.
      #
      # There are other global policies we would like to enforce. For example,
      # "only one experiment can be using the robot testbed." Encoding this kind
      # of policy is harder, and leads down a path that can get arbitrarily
      # complex. Tha path leads to ruination, and so we want to avoid it at
      # all costs.
      #
      # Instead we define a simple global policies table that applies to all
      # experiments currently active on the testbed:
      #
      #   policy:     'nodes', 'type', 'class', 'attribute'
      #     test:     'max', others I cannot think of right now ...
      #    count:     a number
      #  auxdata:     a string
      #
      # Example: A global policy of ('nodes', 'max', 10, '') say that the maximum
      # number of nodes that may be allocated across the testbed is 10. Thats not
      # a very realistic policy of course, but ('type', 'max', 1, 'garcia') says
      # that a max of one garcia can be allocated across the testbed, which
      # effectively means only one experiment will be able to use them at once.
      # This is of course very weak, but I want to step back and give it some
      # more thought before I redo this part.
      #
      # Is that clear? Hope so, cause it gets more complicated. Some admission
      # control tests can be done early in the swap phase, before we really do
      # anything (before assign_wrapper). Others (type and class) tests cannot
      # be done here; only assign can figure out how an experiment is going to map
      # to physical nodes (remember virtual types too), and in that case we need
      # to tell assign what the "constraints" are and let it figure out what is
      # possible.
      #
      # So, in addition to the simple checks we can do, we also generate an array
      # to return to assign_wrapper with the maximum counts of each node type and
      # class that is limited by the policies. assign_wrapper will dump those
      # values into the ptop file so that assign can enforce those maximum values
      # regardless of what hardware is actually available to use. As per discussion
      # with Rob, that will look like:
      #
      #	set-type-limit <type> <limit>
      #
      # and assign will spit out a new type of violation that assign_wrapper will
      # parse.
      #
      # NOTES:
      #
      #  1) Admission control is skipped in admin mode; returns okay.
      #  2) Admission control is skipped when the pid is emulab-ops; returns okay.
      #  3) When calculating current usage, nodes reserved to emulab-ops are
      #     ignored.
      #  4) The sitevar "swap/use_admission_control" controls the use of admission
      #     control; defaults to 1 (on).
      #  5) The current policies can be viewed in the web interface. See
      #     https://www.emulab.net/showpolicies.php3
      #  6) The global policy stuff is weak. I plan to step back and think about it
      #     some more before redoing it, but it will tide us over for now.
      #
      54f55585
  26. 17 Jan, 2005 1 commit
  27. 15 Jan, 2005 2 commits