1. 24 Feb, 2002 5 commits
  2. 21 Feb, 2002 1 commit
    • Leigh Stoller's avatar
      Some whacking of the event system. I have implemented the addressing · 8305021f
      Leigh Stoller authored
      scheme that we discussed in email. Notifications and subscriptions now
      take an "address_tuple" argument (I know, crappy name) that is a
      structure that looks like this:
      
      	char		*site;		/* Which Emulab site. God only */
      	char		*expt;		/* Project and experiment IDs */
      	char		*group;		/* User defined group of nodes */
      	char		*host;		/* A specific host */
      	char		*objtype;	/* LINK, TRAFGEN, etc ... */
              char		*objname;	/* link0, cbr0, cbr1, etc ... */
              char		*eventtype;	/* START, STOP, UP, DOWN, etc ... */
      
      These can be a specific value, ADDRESSTUPLE_ANY if you are a
      subscriber, or ADDRESSTUPLE_ALL if you are a producer. The reason for
      the distinction is that you can optimize the match expression with the
      extra bit of information, and the above structure can make for a
      fairly lengthy match expression, which takes more time of course.
      You should use address_tuple_alloc() and address_tuple_free() rather
      than allocating them yourself. Note that host above is actually the
      ipaddr of control interface. This turns out to be more convenient
      since free nodes do not have virtual names.
      
      Also added a new tbgen directly. This directory includes 3 programs in
      the making:
      
      tbmevd: Is the Testbed Master Event Daemon, to be run on boss and will
      handle TBCONTROL events (reboot, reload, etc). It is just a shell of a
      program right now, that takes the events but does not do anything
      useful with them. Have not defined what the events are, and what DB
      state will be modified.
      
      tbmevc: Is the Testbed Master Event Client (akin to tmcc). It
      generates TBCONTROL events which the tbmevd will pick up and do
      something useful with. This program is intended to be wrapped by a
      perl script that will ask the tmcd for the name of the boss (running
      the event daemon).
      
      sample-client: This is a little client to demonstrate how to connect
      to the event system and use the address tuple to subscribe to events,
      and then how to get information out of notifications.
      
      Note that I have not created a proper build environment yet, so new
      programs should probably go in the event dir for now, and link using
      the same approach as in tbgen/GNUmakefile.in.
      8305021f
  3. 19 Feb, 2002 5 commits
  4. 18 Feb, 2002 1 commit
  5. 14 Feb, 2002 1 commit
  6. 31 Jan, 2002 2 commits
  7. 29 Jan, 2002 7 commits
    • Ian Murdock's avatar
      Added test for event scheduler. · f0fd5d86
      Ian Murdock authored
      f0fd5d86
    • Ian Murdock's avatar
      *** empty log message *** · a3794773
      Ian Murdock authored
      a3794773
    • Ian Murdock's avatar
      *** empty log message *** · 100d3592
      Ian Murdock authored
      100d3592
    • Ian Murdock's avatar
      Added -lpthread to LIBS. · 7c260921
      Ian Murdock authored
      7c260921
    • Ian Murdock's avatar
      Rewrote event scheduler. Event system clients may now call · 29563eb0
      Ian Murdock authored
      event_schedule (see event library), which essentially operates as a
      deferred event_notify. event_schedule accepts a notification and a
      firing time, alters the notification to change the type attribute to
      EVENT_SCHEDULE and add a firing time attribute, and then sends the
      altered notification using event_notify.  The event scheduler
      subscribes to EVENT_SCHEDULE notifications. As they arrive,
      it restores the type in the notification to that of the
      original event and enqueues the notification in a priority queue
      for firing at the indicated time. When the time arrives, the
      scheduler removes the notification from the queue and resends it
      using event_notify.
      
      With these changes, the event system now supports dynamic events.
      29563eb0
    • Ian Murdock's avatar
      7a518579
    • Ian Murdock's avatar
      * Added event_schedule to the event API, which allows events · e9f9388a
      Ian Murdock authored
      to be scheduled at a later time. The interface to event_schedule is
      identical to event_notify, except it takes an additional struct
      timeval argument that specifies when the event should be fired.  We
      assume time synchronization between nodes.
      
      * Revamped the attribute interface. Rather than a single get and put
      function that takes a union "type" argument, we now have separate
      event_notification_get_<type> and event_notification_put_<type>
      functions, where <type> is one of "double", "int32", "int64",
      "opaque", "string". These changes should greatly simply the attribute
      interface. The opaque attribute type is new, and allows
      arbitrary data structures to be added to notifications as attributes.
      
      * Added event_notification_remove, which deletes an attribute from a
      notification.
      
      * Modified the event notification callback to take "host" and "type"
      parameters, which contain the "host" and "type" attributes from the
      event notification, respectively.
      e9f9388a
  8. 19 Dec, 2001 1 commit
  9. 04 Dec, 2001 2 commits
  10. 06 Nov, 2001 4 commits
  11. 02 Nov, 2001 3 commits
  12. 01 Nov, 2001 7 commits