GitLab

Add cnet_ip and phys_nodeid slots, and change the type field enum
adding create and destroy.

Appears to be a known problem (well, feature). So, I added ilo3 as a
type and use that to send the proper termination (formfeed).

Against my better judgement, use configure to set some vars in clientside
scripts. I try to avoid this to keep our client images from becoming Utah
specific.

This is specifically for run_linktest.pl.in, which is installed on both
ops and nodes. I could fix it to not use configure vars on nodes, but that
would break its primary use on ops.

OTOH, I fixed elab_linktest.pl.in to not use configure variables, since
it only runs on nodes.

Previously, openssl had to be installed even with WITH_CRYPTO==0.

Remove non-ascii characters from request stream; never allowed.

out. Revisit later.

For now, do not allow modify either. Still working on that.

Set the hostname for the vnode using vzctl to make sure it gets set
correctly.  Otherwise the vnode will inherit the physical host's
hostname, and since this is not "localhost" or "localhost.localdomain"
the networking scripts inside the container will not set reset it to
the value in /etc/sysconfig/network.

Use the "inside" MAC address rather than the "outside" one when
creating macvlan devices.

Only try to delete interfaces if they still exist when tearing down
the vnode.  The kernel itself automatically deletes "virtual"
interfaces, which includes imq and macvlan.

'git revparse --show-toplevel' is a nice way to get a path to the repo
no matter where you are in it, but unfortunately, older versions don't
have it. So, go back to `pwd`

New 'includepatches' option puts a seperate set of patches after all
commit messages. 'patchstyle' allows you to set 'word' to get word
diffs. 'patchsizelimit' (default 1,000) omits patches with more than
this many lines. 'maxpatches' (default 20) skips patch generation if
there are more than this many commits in the message.

For now, these go into headers (X-Git-Repo-Host and X-Git-Repo-Path)
Might consider moving them to the body of the mail at some point.

Note that I *don't* attempt to figure out the actual 'URL' for the
repo, since that is *not* necessarily automatically derivable: eg.
it might be any of ssh,git, or http protocols, and the path (esp.
for git: and http:) might not match the path in the filesystem. So
this suggests that wat goes into the body of the mail ought to be
set with a config variable.

Show the old and new values of the ref, in a form that is suitable for
passing to 'git log', etc. The idea is to make it easier for the reader
of the mail to go look at more detailed information than is in the mail,
if they so choose.

Use short form of the hashes to make it fit nicely into one line
of text.

Currently supports 'hashes' (like the style supported before), and
'bare', whch omits the hashes (but does do a little indenting)

New option 'commitstyle' currently supports:

   default - default style, includes commig log and summary of changed files
   diff    - include a diff, like 'git show' does by default
   wdiff    - like diff, but word-diff (useful for LaTeX, etc.)

Also a new option 'showcommitargs' that allows you to replace the args to
'git commit' completely. Supercedes the old 'showcommitextra' option,
which we weren't using on any of our repos.

When the new 'summarythreshold' config option is set, gitmail will
produce a summary at the top of the mail. This consists of the
abbreviated commit hash and first line of the log message (truncated
to 72 characters to look nice in mail)

Allow you to specify an arbitrary number of commits (instead of 3)
when using test mode

The recent reboot-node-if-going-from-PXEWAIT-to-SECURELOAD change to
bootinfo was checking that the node was in PXEKERNEL/PXEBOOTING. However,
the transition from PXEWAKEUP->PXEBOOTING may not have happened yet.

However, the check for PXEBOOTING was unnecessary anyway, since bootinfo
is the one that sends that state and it *always* does it just before calling
query_bootinfo_db (the guy relying on the racy state change). Thus, the node
is intended to be in PXEBOOTING even if that hasn't yet been recorded in
the DB. So just remove the state check (we still check the op_mode).

Note that this only affects nodes that are using the secure diskload MFS.

We currently put out a time stamp when we detect output after being idle for
a long time. But the time stamp is the time at which we started getting output
again, so it doesn't give us any idea how long it was idle (i.e., when the
last previous output happened).

So -L changes the format of the stamp from "STAMP{ctime-string}" to
"STAMP{idle@ctime-string}", where "idle" is the number of seconds it has been
since the last output.

This might have been fixed in later gmakes, but at least for the circa-FBSD6
version, the shell PWD variable is not correctly set when a shell script is
run from a make target via:
    $(MAKE) -C foo target
instead of:
    cd foo && $(MAKE) target
In the former case, $PWD would not reflect that it was in "foo".
The upshot is that the tg2.0 tarball was being extracted in the "event"
directory rather than "event/trafgen" so the make rules could not find it.
The same basic shell script worked for iperf and rude because they were
invoked via the latter form.

Anyway, now we just use dir=`pwd` instead of dir=$PWD.