GitLab

Shashi just went by. I bumped the number and added a check for too
many to avoid the core dump. Need a watchdog for this, but I had to
churn another process just for that.

events up (including TIME STARTS) by 5 seconds after ISUP is sent.
Lets see if we can track this down. Also, schedule TIME STARTS like
all other events to see if there is some oddity there.

interupt the current next up event cause Ian's code just grabbed it
off the queue and went into select. I converted this code to use a
condition variable and a timed wait. If a new event comes in, signal
the waiter who can recheck to see of the head of the queue has
changed. Seems to work, but not well tested. This bug reported by Rob!

provides a mapping from an object ($cbr0) to the node on which the
agent is running ($nodeA). It also includes the type of agent
(TRAFGEN, LINK, etc). There were a number of reasons for adding this
table:

* To avoid a series of specialized table lookups in the event
  scheduler to map from a name (link0) to the node on which the agent
  is running. Previously, it was looking the delays table and the
  virt_trafgens table. Well, now it just needs to look at this one
  table and store the mapping internally. When a dynamic event comes
  in, we can figure out where to send it easily.

* For NSE traffic generation. Unlike the simple TG based CBRs, Shashi
  wants to be able to send events to any of the objects in the config
  (udp0, telnet0, ftp0, etc). Well, the virt_trafgens table certainly
  does not store that info, and it would have been painful to work
  this into it. For every agent/application, just add an entry in the
  virt_agents table and the scheduler knows where to send the events.

* It nicely supports the new program object; just plug an entry in the
  virt_agents table.

Okay, there is one messy aspect; delays nodes! Delay nodes are not
computed until after assign wrapper runs, so in addition to munging
the static event list in assign_wrapper, we now munge the virt_agents
table as well. Not much to do about this; delay nodes are handled
outside the normal path everywhere.

1. The tevc client can run on either a client node or on users. The
   command line syntax is like this:

	Usage: ./tevc [-s server] [-c] event
	       ./tevc [-s server] -e pid/eid time objname event [args ...]
	       time: 'now' or '+seconds' or [[[[yy]mm]dd]HH]MMss
	Examples:
	       ./tevc -e pid/eid now cbr0 set interval_=0.2
	       ./tevc -e pid/eid +10 cbr0 start
	       ./tevc -e pid/eid +20 cbr0 stop

   The -s arg defaults to BOSSNODE when not given. Only root can send
   TBCONTROL events (-c), but that part of tevc is probably going to be
   killed off when we convert to sending TBCONTROL via tmcc/tmcd (Rob
   is working on that). The -e option is required for dynamic events,
   and is not defaulted yet.

2. There is no real checking of arguments. The event is sent over to
   the scheduler, which tries to map it into an agent running on a
   node. If the map fails (say, no such trafgen, or no delay node on
   that link), or if the event makes no sense for that agent, the
   event fails and the user never hears about it. The solution for
   this is a back channel so that the scheduler can generate an error
   condition that the user sees.

3. To facilitate better checking, I think we need to change the DB
   tables so that there is a mapping between the type of agent
   (object) and the kinds of events it can take. This would replace
   the flat event_eventtypes table. The event_scheduler could load
   this table at init time so that it can do a quick check on dynamic
   events when they arrive and return an error when we support error
   values.

4. The scheduler initialization phase tries to determine what agents
   are valid for an experiment (thats where you can send events) so
   that when a user sends an event to cbr3, the event scheduler can
   determine what/where that is. My method for determining this is
   totally ad-hoc right now; read the virt_trafgens and delays table.
   These are the only two types of configurable agents we support.
   This is rather bogus! I think assign_wrapper or some other script
   in the front end needs to collect this data into a single table for
   the scheduler to read. Not sure yet; needs more thought. Anyway, I
   build a mapping table that can be searched when a dynamic event
   comes in; this avoids a DB table lookup in the critical path.

the nodes are up and that events are starting. The objtype is "TIME"
(TBDB_OBJECTTYPE_TIME from tbdefs.h) and the eventtype is "START"
(TBDB_EVENTTYPE_START from tbdefs.h). How to subscribe to this event
will be forthcoming.

export that stuff.
Add signal handlers to ensure that INT/TERM/HUP signals are caught and
that we exit cleanly (clearing the pid from the DB).
Minor rework for DB table structure and the switch from per-experiment
event tables to a single event table indexed by pid,eid.

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.

Also several changes for building on FreeBSD. I've left the older
Makefiles in place so Ian can continue to build in his environmant
(Linux?).

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.

sched.h. Renamed sched.c to event-sched.c to match header rename.