GitLab

Magical udev and upstart overrides.

Also, more tweaks for Xen 4.4.

only one of the tags, not all of them.

then 10 connections from the same source in the last 100 seconds. Note
this is just to the physical host itself, it does not affect traffic
to the containers.

pidfile is gone, or the process is gone; both imply
the container is gone, so don't throw an error.

actually being done.

1. Change hackwaitandexit on the client, to return zero if the guest
   has not finished setting up. We used to treat 30 seconds as too
   long must have failed, but this is really not the case, especially
   on busy machines.

2. Fix up vnode_setup exit code handling, we were losing non-zero
   status cause of not shifting it down, and so failures were never
   being reported.

   New: If the vnode setup does return failure, set its event state to
   TBFAILED to cut short the wait in os_setup and the IG monitor
   process. On the surface this seems like an obviously good idea, but
   I'm sure it will come and bite me when I least expect it.

3. Change GeniAggregate Start/Restart to ignore vnode_setup failures,
   and let the monitor watch for TBFAILED or timeout. There are just
   too many ways for it to fail, and we want to allow vnodes that did
   not fail to set up normally, and give the user the choice to
   restart the ones that failed.

4. Don't let frisbee run forever, protect with timeout. I need to use
   Mike's new -T option, but not till I actually get new frisbee
   pushed out.

If we don't get any messages from our server after <sec> seconds,
we exit. Odd that this didn't already exist, huh?

I re-purposed the -T option which used to be used to specify a prefix for
a trace file. Since I am the only one that ever used that option, I don't
feel bad about changing it. Traceprefix is now specified with -U.

slice is busy.  This might mean that the user will not be able to
delete the slice for a long time, but we are having problems with
users canceling slices before they finish setting up, and the XEN
client side is not handling this very well. Note that the cleanupslice
script calls GeniCM::CleanupDeadSlice() directly, which *does* kill
the monitor, so admin cleanup is not affected.

Regarding the xen client side, signals can be blocked for a really
long time while a container is setting up, and so trying to kill it
fails, and bad things ripple out. Fixing that is going to take some
time to get right, so just avoid the problem for now.

1. Add warning 1 hour before expiration, even for "short lived"
   slivers.

2. Auto-delete orphaned cartificates.

3. Try to destroy locked/expired slices before send email about them.

use a patch port instead of a gre tunnel (since it does not work).

error output and attempt to distill into a useful error message
that users might understand.

would take too long!

Just printing the max duration time did not make it clear at whata
point the interval begins.

Also add a simple test script.